Components coupled by design

[oliverschuerch]

As our component library grows, we come to a point, where it is not possible to add only one single component to solve every problem. Sometimes we need multiple components to create one specific experience.

In other words, we need to create multiple components to solve one specific problem.
Let me give you an example:

To create an accordion, we need a wrapper and some accordion-item components.
An accordion-item is getting the content who must be shown or hidden, dependant of the state of itself.
The accordion wrapper component manages all the events, which are coming from its accordion-items. For example if only one open accordion-item is allowed, it closes all the others, when the user is opening a new one.

This two component types are coupled by design and only work properly, if the other component is integrated correctly. So, if you enter an accordion wrapper component without an accordion-item, nothing will show up or work.
If you use multiple accordion-item without an accordion wrapper component, the accordion behavior will not work as expected.

The problem:
The only ones who know (for now) how to integrate these components are humanbeings and off course it is documented in storybook and manually set up in the component stories.
But as far as we want to create this components programmatically (for example to test them), we are not able to do so.

Approach:

1. Lets define, that such components need to have the same naming root (e.g. "accordion", "accordion-item" or "dropdown", "dropdown-item", "dropdown-item-button", "dropdown-separator" ...). So everyone can always recognize they belong together when reading file names or by HTML tags.
2. Lets store those components in the same component folder (e.g. "post-accordion" and "post-accordion-item" are stored under "components/src/components/post-accordion/").
3. To be able to generate component outputs programmatically, we could use a json file which provides the needed informations, such as component relations, required props (incl. possible example values), etc.

{
  "post-accordion": {
    // does not have a coupled parent component
    "parents": [],
      // does have one coupled child component
    "children": [
      {
        "tag": "post-accordion-item",
        "slot": "default"
      }
    ],
    // does not have any required property (can be initialized without any property/attribute)
    "props": []
  },
  "post-accordion-item": {
    // does have one coupled parent component (is probably not working as expected when placed outside this parent component)
    "parents": [
      { "tag": "post-accordion" }
    ]
  }
}

// or

{
"post-tooltip": {
  // does not have a coupled parent component
  "parents": [],
  // does not have a coupled child component
  "children": [],
  // does have one required property/attribute
  "props": [
    {
      "id": "PostTooltip_{uuid}",
    }
  ]
}
}

// or

{
"post-popovercontainer": {
  // only for internal usage, should not be generated anywhere
  "private": true,
  "parents": [],
  "children": [],
  "props": []
}
}

This config json files are small and easy to create (when needed) and can be used to generate for example angular components in the components-angular package. As we might add more frameworks in the future, they could be useful for them as well.

Please share your thoughts!

[oliverschuerch]

We decided to not add thonse config files at the moment and instead add the component manually to the components-angular package.
But to ensure every new component is going to be added, we will add a e2e test which ensures the defined components must be added.