[Feature Request]: Compound Component Detection in Analyzer + Dashboard Integration

[storchk]

📌 Problem

Currently, Omlet detects component usage at the top-level component only. For example:

<Modal>
  <Modal.Header />
  <Modal.Body />
  <Modal.Footer />
</Modal>

is analyzed as:

Modal: 1 usage

However, this misses important usage insights for compound components, which are a common pattern in modern React design systems.

---

🎯 Goal

Extend the analyzer to detect and track compound component usage, such as:

• Modal.Header
• Modal.Body
• Modal.Footer
• (optionally) nested patterns like Modal.Header.Title

---

💡 Expected Behavior

Given:

<Modal>
  <Modal.Header />
  <Modal.Body />
  <Modal.Footer />
</Modal>

Omlet should report:

Modal.: 1
Modal.Header: 1
Modal.Body: 1
Modal.Footer: 1

---

🧠 Motivation / Use Cases

Compound components are widely used in design systems to express composition and structure.

Without this feature, Omlet:

• underreports actual component usage
• cannot distinguish which parts of a component API are used
• limits insights for:
  • API design improvements
  • deprecation decisions
  • usage analytics

This feature would enable:

• granular adoption tracking
• better understanding of component composition patterns
• more accurate design system governance

---

🔧 Proposed scope (MVP)

✅ Direct usage:

<Modal.Header />

❌ Out of scope (for now):

• destructured usage:

const { Header } = Card
<Header />   

• aliasing / re-exports

---

🧩 Proposed dashboard integration

• Extend component details
• List all subcomponents with usage
• Each subcomponent is a link to its own component detail page with available information

---

📊 Data Model Considerations

Two possible approaches:

Option A: Flat structure

Modal
Modal.Header
Modal.Body
Modal.Footer

Option B: Nested structure

{
  "Card": {
    "usage": 1,
    "subComponents": {
      "Header": 1,
      "Body": 1,
      "Footer": 1
    }
  }
}

---

📦 Impact

This feature would significantly improve:

• accuracy of usage analytics
• visibility into real-world component APIs
• decision-making for design system evolution