Discuss if Drupal's theme system should be component driven

https://docs.google.com/document/d/1HEgfgf4isIvkaeyb3Pfo5g6xKjKkQ7B5KoMn...

One fundamental question, which I think needs a lot of input from designers, is whether components that appear on the frontend theme should have the look and feel of the the frontend theme or the admin theme. Up to now we've been doing it based on the admin theme, but I'm not so sure that is the proper design solution.

What we have right now in Drupal core, render elements are the closest thing I can think of to components. Anyway they are hard to use. Anyway, maybe we could use them as a base?

I honestly think that render elements are conceptually exactly what you need. They define the logic how they are rendered as well as the props passed in. Can you please clarify why they are hard to use? Just bitching doens't help.

This could totally be something we could address, once this is solved we could maybe think of renaming render elements, to components, which seems to fit to the thinking model of people much better.

Separating the frontend and the backend is IMHO a decision we should not solve on a lower level but always do that via a theme layer. Please keep in mind that people build UIs in the their frontend as well, in which they would easily want to use the same UI components.

It feels like this issue is missing the main reason for this change. The seperation between the admin interface and the frontend theme is a side benefit. See the motivation in Drupal 9 Components Library: The next theme system:

For every version of Drupal I can remember, if a module wanted to display content, it had to provide the default HTML and CSS for it. This paradigm has served us well for years, but its time to radically improve the re-usability of our HTML and CSS by implementing a core components library.

The problem at the moment is that a lot of available theme templates are based on Drupal's own data structure, not on UI components. The closest thing I've seen to implementing a system of UI components in Drupal is Steve Perch's demonstration of Palantir's workflow of Panels Style Plugins for everything.

Architecturally panels does a lot right by separating style plugins from layout plugins. I'd love to see how we could implement the concept of style plugins in core. What we would need in core is a *good* global API+UI for selecting the component of any source (think template suggestions but for components), and mapping data from any structure -> component variables.

I honestly think that render elements are conceptually exactly what you need.

@dawehner I agree entirely. Render Elements allow you encapsulate a template with it's relevant assets. So technically we already have components system. Renaming it may be helpful for some. I was trying to get that across in the the meeting we had.

We don't have all that great components but we could easily extend or create new Render Elements/Components with the system we have already.

A library of Component/RenderElements may need some thought like @LewisNyman mentioned. What would our required UI components needed for an MVP?

I also believe regarding the admin/front-end theming of components. The theme who is showing the components should implement their own styles for it. That means if Toolbar or Contextual Link components are used on the front end and back end then they should each define theme styles for them.

We can then build up a list of core components that each theme is responsible for. That way we don't have to this difficult technical task of including of styles from other themes depending on different circumstances. It means that Bartik and Seven would have their own styles to maintain for the components (yet the base styles can come from the component). And that way if a BartikBlack came along then they would have the responsibility for dealing with the reversed color Toolbar and Contextual Links.

I think every front-end theme should have the ability to customize the appearance of front-end admin components like the toolbar. However, I don't think that every theme should have to start from scratch doing so.

Admin themes like Seven should be able to provides templates, CSS and JS for front-end admin components so those admin tools can have the same look as back-end admin components.

There is enough to deal with as a front-end developer on a project just implementing the actual design of a site. I have zero desire to start from scratch on a new appearance for the Toolbar for every single site I create. I am fine if by default it looks exactly like the Toolbar on a back-end page. That's my preference in fact.

If I want to make a little tweak (hey, wouldn't it be fun if the toolbar had a purple background color since this site is very purple!), I'd like to be able to do that. But I don't want to be forced to do that.

You wouldn't be forced to start from scratch with the toolbar because as baseline version of that styling would come from the toolbar module itself, as it has been doing before we started moving that CSS around.

I should be more clear.

A front-end UI tool provided by core (or contrib) can have templates, CSS and JS defined in the module itself. However, I think it is a good thing if admin UI is consistent between the front-end and the back-end. That means we need a way for an admin theme to override templates from a module when the front-end theme is being used, not the admin theme. The same is true for CSS and JS.

If people only ever used Seven as an admin theme, this wouldn't be an issue. Then we'd just bake Seven's appearance into the core modules and voila, done. But people will use contrib admin themes eventually (in all likelihood), and I think it's entirely reasonable that those admin themes should be able to influence the appearance of admin UI.

Finally I think in theory the front-end theme should be able to trump the admin theme for front-end UI. This isn't a dealbreaker for me, but if a client or organization feels like some front-end UI needs to look slightly different, I don't think they should need to create an entirely new admin theme in order to make a few tweaks.

The tricky part is that because the Stable theme exists, there are (or will be) overrides of every single template from core within the theme tree. So you couldn't just put the front-end admin overrides in between modules and themes in terms of where things are getting loaded. You'd almost have to put them in the load order between any base themes and the actual active theme. If a theme wants to override front-end admin UI, it would need to do so in the actual active theme, not just in a base theme.

Anyhow, that's my thought process.

Only other note is that in theory contrib modules could also provide front-end admin UI. That's not something we would theme within Seven. But an admin theme might, if there was a really popular contrib-added front-end admin UI.

However, I think it is a good thing if admin UI is consistent between the front-end and the back-end. That means we need a way for an admin theme to override templates from a module when the front-end theme is being used, not the admin theme. The same is true for CSS and JS.

So this is part of the debate, and the big picture discussion. There is an opposing opinion that the admin theme should not be injecting styling into the frontend theme. Basically, what Joel said in #9. In Seattle we were discussing both sides of the argument, and I see merit to both.

I watched John Albin's video from DrupalCon LA that Lewis linked. There is some great discussion there. I'd encourage everyone else to watch it. I'm particularly interested in the strong typing ideas that were brought up.

#1804488: [meta] Introduce a Theme Component Library Related work.