- 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`).
- 🇦🇺Australia RichardGaunt Melbourne
Changes to the extend model
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?
The supported inheritance / extension types of Single Directory Components are:
- Custom component in sub-theme
- Override CivicTheme componentBut not: Extend CivicTheme component - we will be moving more towards the SDC model meaning after the release of SDC you will not be able to extend the original CivicTheme component.
For existing sites that have extended CivicTheme components recommend one of the following options:
1. Convert those components to a overridden component
2. Create a custom component of the original CivicTheme component and extend that in your existing sub-theme componentSingle Directory Components
UI Kit is being converted to support multiple component libraries, the original twig component library will be maintained, there will now be a second component library (Single Directory Components) being maintained.
The original twig component will continue to not include any Drupal specific pieces of functionality.
The Single Directory components will continue to mirror the twig components just the namespacing and the bundling of the component YML and css files will be the changes.
Changes to the UI Kit structure and Design System
This is not part of this project - there is continued discussions but no plans on the evolution of CivicTheme design system. This will be tackled in future issues and plans.
Why SDC
SDC allows CivicTheme to utilise the core component system and opens up future work integrating with experience builder and other new development features appearing within the Drupal ecosystem
- b3995569 committed on 1.x
Issue #3515220 by richardgaunt, alex.skrypnyk, alan.cole: Converted...
- b3995569 committed on 1.x
- Assigned to danielgry
- Status changed to RTBC
12 days ago 1:13pm 25 May 2025