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

e0ipso created an issue. See original summary.

e0ipso’s picture

Issue summary: View changes
e0ipso’s picture

Issue summary: View changes
e0ipso’s picture

I 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.

e0ipso’s picture

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).

e0ipso’s picture

Issue summary: View changes
e0ipso’s picture

I 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.

e0ipso’s picture

Issue summary: View changes
e0ipso’s picture

Title: Allow altering components created elsewhere » [PP-1] Allow altering components created elsewhere
e0ipso’s picture

Title: [PP-1] Allow altering components created elsewhere » Allow altering components created elsewhere
e0ipso’s picture

Status: Active » Fixed

  • e0ipso committed 199f900 on 1.x
    Issue #3293455 by e0ipso, andypost: Allow altering components created...
  • e0ipso committed e1a8268 on 1.x
    Issue #3293455 by e0ipso, andypost: Allow altering components created...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.