Problem/Motivation
Imagine Acme corp, a Drupal agency. They have a component library that they reuse across projects. In there they have accessible components with very sober styling. All those components are packaged in a custom Drupal module acme/acme_base_components.
They use the components in their theme as usual. For instance in the node--article--card.html.twig they have a section with:
{# ... #}
{% include "@acme_base_components/components/acme-button/acme-button--primary.twig" with {
text: 'Click Me',
iconType: 'external'
} %}
{# ... #}
However in their project for Client Inc. they need to tweak the styles, JS, or markup a tiny bit.
Acme should be able to add a component acme-button in the theme for Client Inc. that extends the base acme-button.
Proposed resolution
Take inspiration from component shadowing in Gatsby, or other technologies to propose a solution.
After some discussion in #3050386: Allow loading CSS and JavaScript directly from templates, and in video-chat, we have decided to only support forking/replacing components. If more granularity is needed, one can split the component further to allow overriding each one of the pieces.
The reasoning is that extending components imposes unreasonable maintenance burden on the original component side (core, contrib, etc).
For simplicity, only one component can extend/decorate another.
Comments
Comment #2
e0ipsoComment #3
e0ipsoComment #4
e0ipsoI wonder if the right approach here is not to override a component, but to extend it. Maybe both...
Overriding the component will allow modules to use components in their UIs that get their appearance tweaked when the overriding kicks in. I think this is an edge case.
I am favoring component extension more than alteration at this point.
Comment #5
e0ipsoAfter some discussion in #3050386: Allow loading CSS and JavaScript directly from templates, and in video-chat, we have decided to only support forking/replacing components. If more granularity is needed, one can split the component further to allow overriding each one of the pieces.
The reasoning is that extending components imposes unreasonable maintenance burden on the original component side (core, contrib, etc).
Comment #6
andypostIt reminds me about #2915311: JavaScript VDOM library evaluation: integrating web components
Comment #7
e0ipsoComment #8
e0ipsoI agree @andypost, I think there is some overlap with web components. However I think that web components have deeper implications in:
- How we develop them (the current Drupal workflow might not be the perfect fit).
- How we integrate them in Drupal.
- How the shadow DOM affects sub-theming.
- etc.
That said, many of the things we discover in this experiment and the decisions we make will likely inform decisions in #2915311: JavaScript VDOM library evaluation: integrating web components. Thanks for making the connection.
Comment #9
e0ipsoComment #10
e0ipsoComment #11
e0ipsoComment #12
e0ipso