- Issue created by @RichardGaunt
- 🇦🇺Australia alex.skrypnyk Melbourne
Hi team,
It is great to see this plan.
I'd like to question/clarify a couple of things:
1. Currently, it is possible to override a part of the component, a whole component or create a custom component in the sub-theme. This allows to only override parts of components with a minimum blueprint and, at the same time, rely on upstream. This makes CT-based sites easy to maintain, because only a specific set overrides would need to be supported. Could you please elaborate how this feature change?
2. Currently, the UI kit provides a framework-agnostic styles and markup (yes, Twig is framework-agnostic as any other templating language; it just happened that Drupal and Wordpress uses Twig as well). The UI kit also does not have any "Drupalisms" in it making it usable in other frameworks. Reading the plan above, it looks like that the "Drupalisms" will be added to the UI Kit. Has an alternative been considered? For example, to have a converter from the UI Kit into framework-specific packages, where UI Kit could have a pipeline that would extract the props from the variables and blocks in Twig and put them into a `[name].component.yml` file. With the current Twig implementation this would be trivial to do.
The CT team put a lot of efforts to keep the UI Kit clean from "Drupalism" in the past and it would be a shame to see the framework-specifics to be added to it.3. The simplification of the atomic structure into a flat structure is the way other design systems are going these days. I suggest to still have 3 levels: 'tokens' (all the low-level components - base + atoms), 'components' (all the molecules and organisms), 'pages' (assembled pages - currently there is only `Page`).