LGD components: consolidate?

[ctorgalson]

Disclaimer: I don't know if this issue belongs with localgov_base, but since it's the main and default frontend for the project I'm starting this here.

Having worked on theming a number of LGD projects, I find there's a bit of friction when customizing essentially identical components from different modules (and the theme itself) that, while well-suited to their original use, aren't compatible with other each other.

Mainly, I'm thinking about grid systems--I believe I counted four grid systems in use from LGD sources on one project--and widgets that implement WAI-ARIA patterns such as localgov_step_by_step's and localgov_paragraphs' accordions.

So:

• does this cause enough friction for others that we should think about tackling it when we find obvious duplication of function?
• if so how (and where) should we start to go about it? (I.e. would we override modules' implementations in the theme, or provide SDCs or what-have-you in a module for consumption by themes and modules?)

[andybroomfield]

I think a lgd components module (maybe in localgov_core) could be a useful way of introducing single directory components if we want to go down that route. What is the Drupal core version where they became avalible?

[ctorgalson]

@andybroomfield it's been in core as 'experimental' since Drupal 10.1, and 'stable' since 10.3.

I'm partial to the idea of a module as well, since that would make it available to LGD (and other) modules and localgov_base (and other themes) as an optional requirement if needed/wanted.

[markconroy]

@ctorgalson The reason there is "stuff" in modules and other "stuff" in the theme is because the modules are supposed to be able to be standalone. To make this happen, we were providing templates + css + js in modules, and then overriding all that in the base theme.

We are now at a stage where we only provide basic markup/CSS in (new) modules and let LocalGov Base do most of the heavy lifting.

I think it's a really good idea for us to consolidate what we can - in the base theme or in a module. I kind of prefer doing it at the theme-level, but that might be just because I know the theme so well. Let's not let that stop us.

[ctorgalson]

The reason there is "stuff" in modules and other "stuff" in the theme is because the modules are supposed to be able to be standalone. To make this happen, we were providing templates + css + js in modules, and then overriding all that in the base theme.

Yep. As I mentioned, well-suited to doing the jobs they were built for.

It's why I waffle a bit about where reusable components should come from. If in the theme--where this kind of work already happens, and where the basic infrastructure already exists--then maybe we don't have to introduce a new dependency, but that also means new LGD features/modules can't just use theme components directly (I don't even know: can a module declare a theme as a dependency?)

On the other hand, if from a new module, then maybe the theme gets a new dependency, as do other modules that want to use something already-built for their own purposes.

[andybroomfield]

If components where in a module, theme would be able to style them? Not familliar with how they work but could be useful for say the icon component to be able to use that in a module and localgov_base styling it as needed.

[ctorgalson]

If components where in a module, theme would be able to style them?

The short answer is "yes".

The better answer is "yes," but I think we have to figure out the best practices (or at least I do).

The main questions I have about doing this are how and how much would we style components provided by a module?

Given that:

• most LGD themes will use localgov_base's css and css variables,
• a module can't assume the theme's css and variables will be available
• a module also can't make too many assumptions about the visual presentation that its consumers will need

...I would say we'd probably want to keep component styles to a minimum.

On the other hand, providing SDCs in the context of localgov_base would mean we could provide components that "fit" pretty well by default (so a component could just directly use --vertical-rhythm-spacing for example).

By default, SDCs automatically detect their own library files. This deprives us of the opportunity to declare a CSS file as component or theme as in regular *.libraries.yml files (which helps with overriding, because it affects the order the files are loaded in).

But SDCs can also take responsibility for declaring their own library files explicitly. I think--but haven't tested--that we can use the libraryOverrides key on the component schema file to take complete control of the library declared by the component. If that's true, then we could (by convention) have components declare their CSS as component to make things simpler.

(Added: as far as I know, we can also use libraries-override, libaries-extend etc at the theme level to override an included component's libraries).

[ctorgalson]

It also seems there are some outstanding problems with the order of dependency loading that affect SDCs.