Reconcile components module vs SDC namespaces for SDDS includes/embeds

Waiting to hear back from @Wim Leers and @lauriii on if we need to yank the components modules and hardcode SDC namespaces for demo, so postponing for now.

kristen pol → credited lauriii → .

kristen pol → credited Wim Leers → .

Wim would prefer not to have the dependency though Lauri says it's okay for the demo if we need it.

Reopening for consideration.

Moving to postponed for now until we sort out the components working properly in XB.

Given we are working through a lot of critical issues, I'm doubtful this will be worked on before Barcelona so leaving this as postponed and lowering priority given Lauri was okay with this being a dependency for Barcelona. We can remove afterwards if we don't get to it beforehand.

Someone could work on this. Once this work is done though, we can't look at the components with Storybook, unless we do:

📌 Create SDDS build rules for merging SDC metadata files with UI Kit code Postponed

so that we take the UI Kit components and combine with SDC metadata YAMLs and README.md files such that these components are what are picked up by XB rather than how we've manually combined everything.

I'd say that this issue can be focused just on replacing the components module namespaces with the SDC namespaces so that we can test that once we are unblocked.

Thanks!

Raised MR for replacing the components module namespaces with the SDC namespaces. Kindly review MR !38

Thanks! Assigning to Jacob for review.

I've merged in recent changes and fixes and did a quick test.

I switched to this MR branch and ran `npm run build` and get fatal errors for storybook (expected).

I get these when trying to use XB:

Drupal\Core\Render\Component\Exception\InvalidComponentException: [theme] NULL value found, but a string or an object is required. This may be because the property is empty instead of having data present. If possible fix the source data, use the |default() twig filter, or update the schema to allow multiple types./n[theme] Does not have a value in the enumeration ["light","dark"] in Drupal\Core\Theme\Component\ComponentValidator->validateProps() (line 206 of /var/www/html/web/core/lib/Drupal/Core/Theme/Component/ComponentValidator.php).

Twig\Error\RuntimeError: An exception has been thrown during the rendering of a template ("[level] NULL value found, but a string or an object is required. This may be because the property is empty instead of having data present. If possible fix the source data, use the |default() twig filter, or update the schema to allow multiple types./n[level] Does not have a value in the enumeration ["h1","h2","h3","h4","h5","h6"]"). in Twig\Template->yield() (line 1 of themes/contrib/demo_design_system/components/01-atoms/heading/heading.twig).

Given this is a distraction from our current work which is much more pressing, I'm moving this back to postponed and this won't likely make it into the demo but can be worked on post-Barcelona. Thanks for trying to get it to work!

kristen pol → closed merge request !38

Bumping to major but keeping postponing for more visibility in backlog.

Let's do this one first:

📌 Replace components module namespaces with fully-qualified paths Active

Assigning to Jacob for looking at this further.

It would be good for us to understand what's the advantage of using:

{% include 'civictheme:button' with {

rather than:

{% include '@civictheme/../components/00-atoms/button/button.twig' with {

(which is being used in 📌 Replace components module namespaces with fully-qualified paths Active )

other than it being more succinct. The latter works with non-SDC Drupal code.

I am playing with this same problem space. I am building an organization-specific USWDS (like design.va.gov), with a concept similar to how Emulsify demo’d Western U with multiple in-house brands. The plan is to have Storybooks at those multiple levels, and then at the individual project instance level (Drupal and non-Drupal projects).

So, the Drupal-specific twig muddies the waters.

Still playing. Curious how this pans out.

Gotcha. We will need create build rules that updates the components with the Drupal-y bits as we are starting with a non-Drupal-specific design system: https://github.com/civictheme/uikit

It would be good for us to understand what's the advantage of using:

{% include 'civictheme:button' with {

rather than:

{% include '@civictheme/../components/00-atoms/button/button.twig' with {

I am not fond of include 'civictheme:button':

• it doesn't trigger the component render element (but kind of "simulate" it)
• If used outside of a component (in a "normal" Drupal template), it is often replaceable by a better use of the render API and the display builders: https://www.youtube.com/watch?v=75wRtmpczOM
• if used inside a component template, it is often replaceable by a better use of the slot system

But it is better than include '@civictheme/.../button.twig' (which share the same issues) because it helps us to stop thinking about templates (and its path) and let us focus on components as proper UI objects. The component template (Twig file) must be an implementation detail which must stay opaque. What is really meaningful is the component definition (YAML file).

Thanks so much 🙏 I’ll watch the video (it was on my list!)