@commercetools/nimbus-mcp 0.1.0 → 2.10.0

package/data/docs/routes/components-utilities.json

@@ -0,0 +1,34 @@
+{
+  "meta": {
+    "id": "Components-Utilities",
+    "title": "Utilities",
+    "description": "Low-level or functional components for utility purposes.",
+    "order": 9,
+    "repoPath": "packages/nimbus/src/docs/utilities.mdx",
+    "menu": [
+      "Components",
+      "Utilities"
+    ],
+    "route": "components/utilities",
+    "tags": [
+      "document"
+    ],
+    "toc": [],
+    "icon": "Construction",
+    "layout": "app-frame",
+    "tabs": [
+      {
+        "key": "overview",
+        "title": "Overview",
+        "order": 0
+      }
+    ]
+  },
+  "mdx": "\n# Utilities\n\nLow-level or functional components for utility purposes.\n\n<CategoryOverview variant=\"list\" />\n",
+  "views": {
+    "overview": {
+      "mdx": "\n# Utilities\n\nLow-level or functional components for utility purposes.\n\n<CategoryOverview variant=\"list\" />\n",
+      "toc": []
+    }
+  }
+}

package/data/docs/routes/components.json

@@ -0,0 +1,33 @@
+{
+  "meta": {
+    "id": "Components",
+    "title": "Components",
+    "description": "React components for building robust and visually appealing applications.",
+    "order": 3,
+    "repoPath": "packages/nimbus/src/docs/components.mdx",
+    "menu": [
+      "Components"
+    ],
+    "route": "components",
+    "tags": [
+      "components",
+      "react"
+    ],
+    "toc": [],
+    "layout": "app-frame",
+    "tabs": [
+      {
+        "key": "overview",
+        "title": "Overview",
+        "order": 0
+      }
+    ]
+  },
+  "mdx": "\n# Components\n\n<CategoryOverview />\n",
+  "views": {
+    "overview": {
+      "mdx": "\n# Components\n\n<CategoryOverview />\n",
+      "toc": []
+    }
+  }
+}

package/data/docs/routes/home-contribute-adrs-adr0001-consumer-component-apis.json

@@ -0,0 +1,314 @@
+{
+  "meta": {
+    "id": "Consumer-Component-APIs",
+    "title": "ADR: On Consumer Component API's",
+    "description": "Architecture decision record on how to structure component APIs for flexibility and maintainability",
+    "order": 1,
+    "repoPath": "packages/nimbus/src/docs/architecture-decisions/adr-0001-consumer-component-apis.mdx",
+    "menu": [
+      "Home",
+      "Contribute",
+      "ADR's",
+      "ADR0001 Consumer Component APIs"
+    ],
+    "route": "home/contribute/adrs/adr0001-consumer-component-apis",
+    "tags": [
+      "architecture",
+      "components",
+      "design",
+      "api"
+    ],
+    "toc": [
+      {
+        "value": "Context",
+        "href": "#context",
+        "depth": 2,
+        "numbering": [
+          1,
+          1
+        ],
+        "parent": "root"
+      },
+      {
+        "value": "Early Attempts",
+        "href": "#early-attempts",
+        "depth": 2,
+        "numbering": [
+          1,
+          2
+        ],
+        "parent": "root"
+      },
+      {
+        "value": "Attempt A: One Big Alert with Child Buttons",
+        "href": "#attempt-a-one-big-alert-with-child-buttons",
+        "depth": 3,
+        "numbering": [
+          1,
+          2,
+          1
+        ],
+        "parent": "root"
+      },
+      {
+        "value": "Attempt B: Specialized Props for Each Slot",
+        "href": "#attempt-b-specialized-props-for-each-slot",
+        "depth": 3,
+        "numbering": [
+          1,
+          2,
+          2
+        ],
+        "parent": "root"
+      },
+      {
+        "value": "Attempt C: Even More Props for Layout / Positioning",
+        "href": "#attempt-c-even-more-props-for-layout--positioning",
+        "depth": 3,
+        "numbering": [
+          1,
+          2,
+          3
+        ],
+        "parent": "root"
+      },
+      {
+        "value": "Final Decision: Compound Components",
+        "href": "#final-decision-compound-components",
+        "depth": 2,
+        "numbering": [
+          1,
+          3
+        ],
+        "parent": "root"
+      },
+      {
+        "value": "Key Changes:",
+        "href": "#key-changes",
+        "depth": 3,
+        "numbering": [
+          1,
+          3,
+          1
+        ],
+        "parent": "root"
+      },
+      {
+        "value": "Why this is better:",
+        "href": "#why-this-is-better",
+        "depth": 3,
+        "numbering": [
+          1,
+          3,
+          2
+        ],
+        "parent": "root"
+      },
+      {
+        "value": "Consequences",
+        "href": "#consequences",
+        "depth": 2,
+        "numbering": [
+          1,
+          4
+        ],
+        "parent": "root"
+      },
+      {
+        "value": "Examples in Practice",
+        "href": "#examples-in-practice",
+        "depth": 2,
+        "numbering": [
+          1,
+          5
+        ],
+        "parent": "root"
+      },
+      {
+        "value": "1. Basic Alert",
+        "href": "#1-basic-alert",
+        "depth": 3,
+        "numbering": [
+          1,
+          5,
+          1
+        ],
+        "parent": "root"
+      },
+      {
+        "value": "2. Alert with Extra Controls",
+        "href": "#2-alert-with-extra-controls",
+        "depth": 3,
+        "numbering": [
+          1,
+          5,
+          2
+        ],
+        "parent": "root"
+      },
+      {
+        "value": "Summary",
+        "href": "#summary",
+        "depth": 2,
+        "numbering": [
+          1,
+          6
+        ],
+        "parent": "root"
+      }
+    ],
+    "layout": "app-frame",
+    "tabs": [
+      {
+        "key": "overview",
+        "title": "Overview",
+        "order": 0
+      }
+    ]
+  },
+  "mdx": "\n# ADR: On Consumer Component API's\n\n## Context\n\nWe needed an Alert component to show informational or warning messages. The\ncomponent should allow:\n\n- A title and description.\n- An optional dismiss button.\n- Additional buttons or controls.\n- Spacing/styling overrides (e.g. px, py).\n\nIn early explorations, we tried to expose everything via props on the main\n`Alert`—this seemed convenient but would quickly became unwieldy when\nrequirements changed. This led to a discussion about how to structure the API\nfor components in a way that is both flexible and maintainable.\n\n## Early Attempts\n\n### Attempt A: One Big Alert with Child Buttons\n\n```jsx\n<Alert\n  title=\"title\"\n  description=\"description\"\n  onDismiss={() => void}\n  px=\"4\"\n  py=\"2\"\n>\n  <button>Dismiss</button>\n  <button>Click me</button>\n</Alert>\n```\n\n1. title and description are top-level props.\n2. children are the alert's buttons.\n\n**Issue**: If we need new kinds of controls (e.g., a link, extra text, or\nre-positioned buttons), we must keep adding or repurposing props. The line\nbetween \"belongs in children\" vs. \"belongs in dedicated props\" can become\nblurry.\n\n### Attempt B: Specialized Props for Each Slot\n\n```jsx\n<Alert\n  alertTitleStyle=\"bold\"\n  title=\"title\"\n  description=\"description\"\n  onDismiss={() => void}\n  px=\"4\"\n  py=\"2\"\n  alertControls={\n    <>\n      <button>Dismiss</button>\n      <button>Click me</button>\n    </>\n  }\n/>\n```\n\n1. We introduced an alertControls prop for the buttons.\n2. We also added alertTitleStyle to control how the title looks.\n\n**Issue**: As the design evolves (e.g., \"Now we need the title right‐aligned, or\na sub‐title below the main title\"), we keep adding ad-hoc props like\ntitlePosition, alertControlsAlignment, etc. The `<Alert>` props list grows large\nand messy.\n\n### Attempt C: Even More Props for Layout / Positioning\n\n```jsx\n<Alert\n  alertTitleStyle=\"bold\"\n  title=\"title\"\n  titlePosition=\"right\"\n  description=\"description\"\n  onDismiss={() => void}\n  px=\"4\"\n  py=\"2\"\n  alertControls={\n    <>\n      <button>Dismiss</button>\n      <button>Click me</button>\n    </>\n  }\n/>\n```\n\n**Issue**: The top-level `<Alert>` component now has numerous styling, layout,\nand content props all jumbled together. If a new design wants a second dismiss\nbutton or a multi-line description, we must add more props. This is non-scalable\nand not very semantic.\n\n## Final Decision: Compound Components\n\nWe decided to adopt compound components (a pattern in which sub-elements are\nalso React components). The final API looks like:\n\n```jsx\n<Alert px=\"4\" py=\"2\">\n  <Alert.Title fontStyle=\"bold\">\n    Alert Title\n  </Alert.Title>\n  <Alert.Description>\n    A short alert description.\n  </Alert.Description>\n  <Alert.DismissButton onClick={() => void} />\n</Alert>\n```\n\n### Key Changes:\n\n1. Children become semantic slots: `<Alert.Title>`, `<Alert.Description>`, and\n   `<Alert.DismissButton>`.\n2. Each slot can handle its own styling or props. For instance, Alert.Title\n   might accept a fontStyle prop, Alert.DismissButton handles its own click\n   event.\n3. The root `<Alert>` only handles general layout or high-level variant props\n   (e.g., px, py, severity).\n\n### Why this is better:\n\n- **Clear separation of concerns**: Layout/styling for each slot belongs to that\n  slot. The main `<Alert>` only handles spacing or theming.\n- **Easier to extend**: If we need a second sub-element (e.g., `<Alert.Icon>` or\n  `<Alert.Footer>`), we just introduce a new subcomponent. We don't clog\n  `<Alert>` with more props.\n- **Semantic**: `<Alert.Title>` and `<Alert.Description>` are more descriptive\n  than `title=\"...\"` or `alertControls={...}`.\n\n## Consequences\n\n- We have a more verbose but much more flexible API.\n- Consumers build their alert in a semantic, composable way.\n- We can add or rearrange subcomponents without rewriting the main `<Alert>`\n  props or code.\n- If developers want quick usage (like a single short message), they might find\n  passing a couple props simpler – but we've prioritized long-term\n  maintainability and clarity.\n\n## Examples in Practice\n\n### 1. Basic Alert\n\n```jsx\n<Alert>\n  <Alert.Title>Warning!</Alert.Title>\n  <Alert.Description>Please fill out all required fields.</Alert.Description>\n  <Alert.DismissButton onClick={onClose} />\n</Alert>\n```\n\n### 2. Alert with Extra Controls\n\n```jsx\n<Alert px=\"4\" py=\"3\">\n  <Alert.Title fontStyle=\"bold\">Network Error</Alert.Title>\n  <Alert.Description>\n    We could not reach the server. Please try again.\n  </Alert.Description>\n  <Alert.DismissButton onClick={onClose} />\n  <Alert.Controls>\n    <Button onClick={onRetry}>Retry</Button>\n  </Alert.Controls>\n</Alert>\n```\n\n## Summary\n\n- Inline props for major sections quickly lead to \"prop creep.\"\n- Compound components keep `<Alert>` minimal and delegate content/markup details\n  to semantically named subcomponents.\n- Layout changes or extra features do not require new top-level props on\n  `<Alert>`.\n\nThis approach scales better and is more maintainable as the design evolves.\n",
+  "views": {
+    "overview": {
+      "mdx": "\n# ADR: On Consumer Component API's\n\n## Context\n\nWe needed an Alert component to show informational or warning messages. The\ncomponent should allow:\n\n- A title and description.\n- An optional dismiss button.\n- Additional buttons or controls.\n- Spacing/styling overrides (e.g. px, py).\n\nIn early explorations, we tried to expose everything via props on the main\n`Alert`—this seemed convenient but would quickly became unwieldy when\nrequirements changed. This led to a discussion about how to structure the API\nfor components in a way that is both flexible and maintainable.\n\n## Early Attempts\n\n### Attempt A: One Big Alert with Child Buttons\n\n```jsx\n<Alert\n  title=\"title\"\n  description=\"description\"\n  onDismiss={() => void}\n  px=\"4\"\n  py=\"2\"\n>\n  <button>Dismiss</button>\n  <button>Click me</button>\n</Alert>\n```\n\n1. title and description are top-level props.\n2. children are the alert's buttons.\n\n**Issue**: If we need new kinds of controls (e.g., a link, extra text, or\nre-positioned buttons), we must keep adding or repurposing props. The line\nbetween \"belongs in children\" vs. \"belongs in dedicated props\" can become\nblurry.\n\n### Attempt B: Specialized Props for Each Slot\n\n```jsx\n<Alert\n  alertTitleStyle=\"bold\"\n  title=\"title\"\n  description=\"description\"\n  onDismiss={() => void}\n  px=\"4\"\n  py=\"2\"\n  alertControls={\n    <>\n      <button>Dismiss</button>\n      <button>Click me</button>\n    </>\n  }\n/>\n```\n\n1. We introduced an alertControls prop for the buttons.\n2. We also added alertTitleStyle to control how the title looks.\n\n**Issue**: As the design evolves (e.g., \"Now we need the title right‐aligned, or\na sub‐title below the main title\"), we keep adding ad-hoc props like\ntitlePosition, alertControlsAlignment, etc. The `<Alert>` props list grows large\nand messy.\n\n### Attempt C: Even More Props for Layout / Positioning\n\n```jsx\n<Alert\n  alertTitleStyle=\"bold\"\n  title=\"title\"\n  titlePosition=\"right\"\n  description=\"description\"\n  onDismiss={() => void}\n  px=\"4\"\n  py=\"2\"\n  alertControls={\n    <>\n      <button>Dismiss</button>\n      <button>Click me</button>\n    </>\n  }\n/>\n```\n\n**Issue**: The top-level `<Alert>` component now has numerous styling, layout,\nand content props all jumbled together. If a new design wants a second dismiss\nbutton or a multi-line description, we must add more props. This is non-scalable\nand not very semantic.\n\n## Final Decision: Compound Components\n\nWe decided to adopt compound components (a pattern in which sub-elements are\nalso React components). The final API looks like:\n\n```jsx\n<Alert px=\"4\" py=\"2\">\n  <Alert.Title fontStyle=\"bold\">\n    Alert Title\n  </Alert.Title>\n  <Alert.Description>\n    A short alert description.\n  </Alert.Description>\n  <Alert.DismissButton onClick={() => void} />\n</Alert>\n```\n\n### Key Changes:\n\n1. Children become semantic slots: `<Alert.Title>`, `<Alert.Description>`, and\n   `<Alert.DismissButton>`.\n2. Each slot can handle its own styling or props. For instance, Alert.Title\n   might accept a fontStyle prop, Alert.DismissButton handles its own click\n   event.\n3. The root `<Alert>` only handles general layout or high-level variant props\n   (e.g., px, py, severity).\n\n### Why this is better:\n\n- **Clear separation of concerns**: Layout/styling for each slot belongs to that\n  slot. The main `<Alert>` only handles spacing or theming.\n- **Easier to extend**: If we need a second sub-element (e.g., `<Alert.Icon>` or\n  `<Alert.Footer>`), we just introduce a new subcomponent. We don't clog\n  `<Alert>` with more props.\n- **Semantic**: `<Alert.Title>` and `<Alert.Description>` are more descriptive\n  than `title=\"...\"` or `alertControls={...}`.\n\n## Consequences\n\n- We have a more verbose but much more flexible API.\n- Consumers build their alert in a semantic, composable way.\n- We can add or rearrange subcomponents without rewriting the main `<Alert>`\n  props or code.\n- If developers want quick usage (like a single short message), they might find\n  passing a couple props simpler – but we've prioritized long-term\n  maintainability and clarity.\n\n## Examples in Practice\n\n### 1. Basic Alert\n\n```jsx\n<Alert>\n  <Alert.Title>Warning!</Alert.Title>\n  <Alert.Description>Please fill out all required fields.</Alert.Description>\n  <Alert.DismissButton onClick={onClose} />\n</Alert>\n```\n\n### 2. Alert with Extra Controls\n\n```jsx\n<Alert px=\"4\" py=\"3\">\n  <Alert.Title fontStyle=\"bold\">Network Error</Alert.Title>\n  <Alert.Description>\n    We could not reach the server. Please try again.\n  </Alert.Description>\n  <Alert.DismissButton onClick={onClose} />\n  <Alert.Controls>\n    <Button onClick={onRetry}>Retry</Button>\n  </Alert.Controls>\n</Alert>\n```\n\n## Summary\n\n- Inline props for major sections quickly lead to \"prop creep.\"\n- Compound components keep `<Alert>` minimal and delegate content/markup details\n  to semantically named subcomponents.\n- Layout changes or extra features do not require new top-level props on\n  `<Alert>`.\n\nThis approach scales better and is more maintainable as the design evolves.\n",
+      "toc": [
+        {
+          "value": "Context",
+          "href": "#context",
+          "depth": 2,
+          "numbering": [
+            1,
+            1
+          ],
+          "parent": "root"
+        },
+        {
+          "value": "Early Attempts",
+          "href": "#early-attempts",
+          "depth": 2,
+          "numbering": [
+            1,
+            2
+          ],
+          "parent": "root"
+        },
+        {
+          "value": "Attempt A: One Big Alert with Child Buttons",
+          "href": "#attempt-a-one-big-alert-with-child-buttons",
+          "depth": 3,
+          "numbering": [
+            1,
+            2,
+            1
+          ],
+          "parent": "root"
+        },
+        {
+          "value": "Attempt B: Specialized Props for Each Slot",
+          "href": "#attempt-b-specialized-props-for-each-slot",
+          "depth": 3,
+          "numbering": [
+            1,
+            2,
+            2
+          ],
+          "parent": "root"
+        },
+        {
+          "value": "Attempt C: Even More Props for Layout / Positioning",
+          "href": "#attempt-c-even-more-props-for-layout--positioning",
+          "depth": 3,
+          "numbering": [
+            1,
+            2,
+            3
+          ],
+          "parent": "root"
+        },
+        {
+          "value": "Final Decision: Compound Components",
+          "href": "#final-decision-compound-components",
+          "depth": 2,
+          "numbering": [
+            1,
+            3
+          ],
+          "parent": "root"
+        },
+        {
+          "value": "Key Changes:",
+          "href": "#key-changes",
+          "depth": 3,
+          "numbering": [
+            1,
+            3,
+            1
+          ],
+          "parent": "root"
+        },
+        {
+          "value": "Why this is better:",
+          "href": "#why-this-is-better",
+          "depth": 3,
+          "numbering": [
+            1,
+            3,
+            2
+          ],
+          "parent": "root"
+        },
+        {
+          "value": "Consequences",
+          "href": "#consequences",
+          "depth": 2,
+          "numbering": [
+            1,
+            4
+          ],
+          "parent": "root"
+        },
+        {
+          "value": "Examples in Practice",
+          "href": "#examples-in-practice",
+          "depth": 2,
+          "numbering": [
+            1,
+            5
+          ],
+          "parent": "root"
+        },
+        {
+          "value": "1. Basic Alert",
+          "href": "#1-basic-alert",
+          "depth": 3,
+          "numbering": [
+            1,
+            5,
+            1
+          ],
+          "parent": "root"
+        },
+        {
+          "value": "2. Alert with Extra Controls",
+          "href": "#2-alert-with-extra-controls",
+          "depth": 3,
+          "numbering": [
+            1,
+            5,
+            2
+          ],
+          "parent": "root"
+        },
+        {
+          "value": "Summary",
+          "href": "#summary",
+          "depth": 2,
+          "numbering": [
+            1,
+            6
+          ],
+          "parent": "root"
+        }
+      ]
+    }
+  }
+}

package/data/docs/routes/home-contribute-adrs-adr0002-compound-component-extraction.json

@@ -0,0 +1,160 @@
+{
+  "meta": {
+    "id": "Compound-Component-Extraction",
+    "title": "ADR: Standardizing Compound Component Extraction to a `components` Directory",
+    "description": "Architecture decision record on organizing compound component implementations",
+    "order": 2,
+    "repoPath": "packages/nimbus/src/docs/architecture-decisions/adr-0002-compound-component-extraction.mdx",
+    "menu": [
+      "Home",
+      "Contribute",
+      "ADR's",
+      "ADR0002 Compound Component Extraction"
+    ],
+    "route": "home/contribute/adrs/adr0002-compound-component-extraction",
+    "tags": [
+      "architecture",
+      "components",
+      "directory-structure",
+      "organization"
+    ],
+    "toc": [
+      {
+        "value": "Context",
+        "href": "#context",
+        "depth": 2,
+        "numbering": [
+          1,
+          1
+        ],
+        "parent": "root"
+      },
+      {
+        "value": "Decision",
+        "href": "#decision",
+        "depth": 2,
+        "numbering": [
+          1,
+          2
+        ],
+        "parent": "root"
+      },
+      {
+        "value": "Why this is better:",
+        "href": "#why-this-is-better",
+        "depth": 2,
+        "numbering": [
+          1,
+          3
+        ],
+        "parent": "root"
+      },
+      {
+        "value": "Consequences",
+        "href": "#consequences",
+        "depth": 2,
+        "numbering": [
+          1,
+          4
+        ],
+        "parent": "root"
+      },
+      {
+        "value": "Examples",
+        "href": "#examples",
+        "depth": 2,
+        "numbering": [
+          1,
+          5
+        ],
+        "parent": "root"
+      },
+      {
+        "value": "Summary",
+        "href": "#summary",
+        "depth": 2,
+        "numbering": [
+          1,
+          6
+        ],
+        "parent": "root"
+      }
+    ],
+    "layout": "app-frame",
+    "tabs": [
+      {
+        "key": "overview",
+        "title": "Overview",
+        "order": 0
+      }
+    ]
+  },
+  "mdx": "\n# ADR: Standardizing Compound Component Extraction to a `components` Directory\n\n## Context\n\nTo enhance the organization, maintainability, and scalability of our components\nthat utilize the compound component pattern, we are establishing a consistent\ndirectory structure for their implementation. This ADR outlines the principle of\nextracting the core root component and its associated compound sub-components\ninto a dedicated `components` subdirectory.\n\n## Decision\n\nFor any component (`<ComponentName>`) that follows the compound component\npattern (where sub-components like `<ComponentName.Part>`,\n`<ComponentName.Control>`, etc., are defined as properties of the main\ncomponent), we will adopt the following directory structure:\n\n- The main component's directory will be\n  `packages/nimbus/src/components/<component-name>/`.\n- A subdirectory named `components` will be created within the main component's\n  directory: `packages/nimbus/src/components/<component-name>/components/`.\n- The implementation files for the root component (`<ComponentName.Root>`) and\n  all its compound sub-components (`<ComponentName.Part>`,\n  `<ComponentName.Control>`, etc.) will reside within this `components`\n  subdirectory.\n- The main `<component-name>.tsx` file within the `<component-name>` directory\n  will be responsible for:\n  - Importing the root component and all sub-components from the `components`\n    subdirectory.\n  - Re-exporting them as properties of the main `ComponentName` object.\n\nStorybook files (`<component-name>.stories.tsx`) will be updated to reflect this\nstructure, primarily by referencing the appropriate root component (e.g.,\n`ComponentName.Root` or `ComponentName`) in the `Meta` configuration.\n\n## Why this is better:\n\n- **Consistent Code Organization:** This standardized structure will make it\n  easier for developers to locate the implementation files for any component\n  utilizing the compound pattern.\n- **Improved Maintainability:** Isolating the implementation of each part of a\n  compound component within its own file reduces the complexity of individual\n  files and minimizes the risk of unintended side effects during modifications.\n- **Enhanced Scalability:** As components grow and incorporate more\n  sub-components, this structure provides a clear and manageable way to organize\n  the increasing number of files.\n- **Clear Separation of Concerns:** Each file within the `components` directory\n  will focus on the implementation details of a specific part of the compound\n  component.\n\n## Consequences\n\n- **New Directory Structure:** Developers will need to be aware of this new\n  directory structure for all future and refactored compound components.\n- **Import Path Updates:** When working directly with the individual root or\n  sub-component implementations, import paths will need to reflect their\n  location within the `components` subdirectory. However, the main `index.tsx`\n  re-export should abstract this for most consumers using the compound component\n  API.\n- **Storybook Updates:** The `Meta` configuration in Storybook files for\n  compound components will need to point to the appropriate root component.\n\n## Examples\n\n**With `components` Subdirectory:**\n\n```\npackages/nimbus/src/components/component-name/index.tsx\npackages/nimbus/src/components/component-name/component-name.tsx\npackages/nimbus/src/components/component-name/components/component-name.root.tsx\npackages/nimbus/src/components/component-name/components/component-name.part.tsx\npackages/nimbus/src/components/component-name/components/component-name.control.tsx\npackages/nimbus/src/components/component-name/component-name.stories.tsx\n```\n\n## Summary\n\nAdopting this standardized directory structure for compound components will lead\nto a more organized, maintainable, and scalable UI Kit. By consistently\nseparating the implementation details of the root and sub-components into a\ndedicated `components` subdirectory, we establish a clear pattern for future\ndevelopment and refactoring efforts.\n",
+  "views": {
+    "overview": {
+      "mdx": "\n# ADR: Standardizing Compound Component Extraction to a `components` Directory\n\n## Context\n\nTo enhance the organization, maintainability, and scalability of our components\nthat utilize the compound component pattern, we are establishing a consistent\ndirectory structure for their implementation. This ADR outlines the principle of\nextracting the core root component and its associated compound sub-components\ninto a dedicated `components` subdirectory.\n\n## Decision\n\nFor any component (`<ComponentName>`) that follows the compound component\npattern (where sub-components like `<ComponentName.Part>`,\n`<ComponentName.Control>`, etc., are defined as properties of the main\ncomponent), we will adopt the following directory structure:\n\n- The main component's directory will be\n  `packages/nimbus/src/components/<component-name>/`.\n- A subdirectory named `components` will be created within the main component's\n  directory: `packages/nimbus/src/components/<component-name>/components/`.\n- The implementation files for the root component (`<ComponentName.Root>`) and\n  all its compound sub-components (`<ComponentName.Part>`,\n  `<ComponentName.Control>`, etc.) will reside within this `components`\n  subdirectory.\n- The main `<component-name>.tsx` file within the `<component-name>` directory\n  will be responsible for:\n  - Importing the root component and all sub-components from the `components`\n    subdirectory.\n  - Re-exporting them as properties of the main `ComponentName` object.\n\nStorybook files (`<component-name>.stories.tsx`) will be updated to reflect this\nstructure, primarily by referencing the appropriate root component (e.g.,\n`ComponentName.Root` or `ComponentName`) in the `Meta` configuration.\n\n## Why this is better:\n\n- **Consistent Code Organization:** This standardized structure will make it\n  easier for developers to locate the implementation files for any component\n  utilizing the compound pattern.\n- **Improved Maintainability:** Isolating the implementation of each part of a\n  compound component within its own file reduces the complexity of individual\n  files and minimizes the risk of unintended side effects during modifications.\n- **Enhanced Scalability:** As components grow and incorporate more\n  sub-components, this structure provides a clear and manageable way to organize\n  the increasing number of files.\n- **Clear Separation of Concerns:** Each file within the `components` directory\n  will focus on the implementation details of a specific part of the compound\n  component.\n\n## Consequences\n\n- **New Directory Structure:** Developers will need to be aware of this new\n  directory structure for all future and refactored compound components.\n- **Import Path Updates:** When working directly with the individual root or\n  sub-component implementations, import paths will need to reflect their\n  location within the `components` subdirectory. However, the main `index.tsx`\n  re-export should abstract this for most consumers using the compound component\n  API.\n- **Storybook Updates:** The `Meta` configuration in Storybook files for\n  compound components will need to point to the appropriate root component.\n\n## Examples\n\n**With `components` Subdirectory:**\n\n```\npackages/nimbus/src/components/component-name/index.tsx\npackages/nimbus/src/components/component-name/component-name.tsx\npackages/nimbus/src/components/component-name/components/component-name.root.tsx\npackages/nimbus/src/components/component-name/components/component-name.part.tsx\npackages/nimbus/src/components/component-name/components/component-name.control.tsx\npackages/nimbus/src/components/component-name/component-name.stories.tsx\n```\n\n## Summary\n\nAdopting this standardized directory structure for compound components will lead\nto a more organized, maintainable, and scalable UI Kit. By consistently\nseparating the implementation details of the root and sub-components into a\ndedicated `components` subdirectory, we establish a clear pattern for future\ndevelopment and refactoring efforts.\n",
+      "toc": [
+        {
+          "value": "Context",
+          "href": "#context",
+          "depth": 2,
+          "numbering": [
+            1,
+            1
+          ],
+          "parent": "root"
+        },
+        {
+          "value": "Decision",
+          "href": "#decision",
+          "depth": 2,
+          "numbering": [
+            1,
+            2
+          ],
+          "parent": "root"
+        },
+        {
+          "value": "Why this is better:",
+          "href": "#why-this-is-better",
+          "depth": 2,
+          "numbering": [
+            1,
+            3
+          ],
+          "parent": "root"
+        },
+        {
+          "value": "Consequences",
+          "href": "#consequences",
+          "depth": 2,
+          "numbering": [
+            1,
+            4
+          ],
+          "parent": "root"
+        },
+        {
+          "value": "Examples",
+          "href": "#examples",
+          "depth": 2,
+          "numbering": [
+            1,
+            5
+          ],
+          "parent": "root"
+        },
+        {
+          "value": "Summary",
+          "href": "#summary",
+          "depth": 2,
+          "numbering": [
+            1,
+            6
+          ],
+          "parent": "root"
+        }
+      ]
+    }
+  }
+}