Compatibility of SDC use with display/experience builders

that's at least major given the impact

Component blocks (Albeit with ui patterns 1) probably has some code that can be referenced here -

• 1 block per component per entity-type (for context reasons)
• entity field support with formatters (via above context)
• token support

I agree with the diagnosis and the end goal, and I think shoving components in template is a necessary step.

We do not have a way to site build the components in core yet. We shouldn't wait to have it to make the components so having template call components is a way to let the community start the components and use it in core. When we have the capability to site build all this yes we need to make use of that capability and stop hardcoding the components in template.

Probably only tangentially related, and off topic. But my mid-term goal would be to replace render arrays (and maybe Form API) with components as well.

Without having dug too much into this yet, my question is: is this specific of SDC adoption? Or is it also a problem where templates for entities (et al) are not thin wrappers for the render array?

In other words, would it have been a problem as well with the older version of the template you linked in the IS as an example?

(added Component Blocks to the IS)

I would love to see more activity on ✨ [META] Expose Title and other base fields in Manage Display Active - that is the primary blocker to configurable entity rendering and it's been open for ten years. We shouldn't be hard-coding field rendering in any core entity templates.

Tagging for summary (and title) update based on #6 and #7.

@nod_:

I agree with the diagnosis and the end goal, and I think shoving components in template is a necessary step.

So, we may need to introduce a way of safe way for the site builders and/or the developers of those display builder tools to print directly the display without loading those wrapper templates.

Maybe, a checkbox in Manage Display page to skip #theme => node and others... There are so many mechanism relying on this layer, I don't know how to this without breaking things.

@e0ipso:

Probably only tangentially related, and off topic. But my mid-term goal would be to replace render arrays (and maybe Form API) with components as well.

A big subject :) About Render API. I would want yo get rid of render arrays too, but not all of them. I have the feeling SDC can replace all hook themes and all render elements but 4: component, inline_template, html_tag & link.

Such a flesh out Render API would be a dream, but I would keep the render arrays which are declarative, nestable, alterable, seralizable, and have power features like attachments, cache management...

I did a talk about this last month at French Drupal Camp (in English): https://docs.google.com/presentation/d/1Y6tJ4OOJTtCO5lVxEessDlpcRjr33i-p... and I would be happy to discuss about this in another thread.

About Form API. We (UI Patterns people) are trying to integrate UI components (our own format before, SDC format now) with Form API for years now, without success. It would be a dream to get rid of Form Elements and use a superset of SDC to build forms. Di you already have an idea about how to do it? We can discuss about this in a dedicated issue.

@e0ipso:

is this specific of SDC adoption? Or is it also a problem where templates for entities (et al) are not thin wrappers for the render array?

It was already a problem before SDC adoption, but SDC is putting a spotlight on it and may make the situation worse:

• if the SDC component is only deporting the existing wrapper to its own template, we now have a 2 layers of wrappers without any benefit:
  • the original template (node.html.twig, user.html.twig, field.html.twig, block.html.twig, views.html.twig...) is till here and even a thinner layer than before
  • we introduced a meaningless, barely reusable, and confusing SDC component
• if the SDC component is adding markup and logic to the template, we are making this issue more difficult to deal with once we will be able to site build the components in core.

I don't see any situation where SDC is winning here.

We have many templates which will shine as SDC components because they are reusable well-defined UI objects: status-messages.html.twig, breadcrumb.html.twig, table.html.twig, image.html.twig, username.html.twig, pager.html.twig, menu.html.twig... Let's focus on them.

Great slides @pdureau - is there a recording anywhere?

Thanks for your feedback @larowlan

There is a recording, but audio only, and in French, so not very useful: https://m.youtube.com/watch?v=APabn8oYr6w

I'm learning French so it actually is useful because I need the practise 😂 - thanks!

Just found (and re-opened) the original issue which led to this one, and I think the way that SDC was implemented is specifically compounding an existing problem and making it a lot harder to fix. When the template/sdc is for something that's not an entity, then it's a bit diifferent, but the more we use template overrides and sdcs for entity rendering itself, we're making things incompatible with manage display/layout builder - essentially breaking parts of core that would otherwise more or less work.

It was already a problem before SDC adoption, but SDC is putting a spotlight on it and may make the situation worse:

In other hand we have CSS and javascript better. So in my point of view every decision and especially restrictions should be discussed.

@catch in the ticket you just reopened
1. CSS became better.
2. Still exists ability to reuse this template for comment twig.
3. a bit more complicated twig but more structured.

I thought today and would also like to discuss some points in the IS and comments.

So, because the call to this component is now hardcoded

Not now. It's worked this way since Olivero's beginning.
Now there is an SDC layer that greatly simplifies and improves the styles of the teaser and potentially other components (I want to use it for comments).

But in general, rolling back that Olivero teaser task will not change anything for those modules from the list.

hardcoded

I can't call it hardcode.
This is a completely valid and the ONLY way (for now) (unfortunately) in the core to implement components.
Those methods that require manipulation in the admin panel and complex config synchronisation may also not be liked by all members of the community.
I will be very glad when core can offer something different for components.
But this moment obviously has not yet arrived.

It would be a pity if Olivero, the default Drupal theme, is becoming incompatible with the strategy of targeting the ambitious site builders by improving the display building experience.

I personally don't like that Olivero doesn't always strictly follow BEM.
Contains unnecessary style cascades and so on.
I also believe that the developers of these ambitious initiatives are very strong and they will be able to rewrite and adapt any template.
And it will be much easier for them to do this if it will be good component from a front-end point of view. Even if implemented through Twig.

now have 2 layers of wrappers without gaining any benefit

Benefit is clean frontend. Smaller flat tree.

I don't see any situation where SDC is winning here.

It is not win of SDC but win of frontend component development approach. SDC is tool here.

But we are not there yet and it may be hard for the SDC enthusiasts and early adopters to project themselves into a future where we use SDC components mainly from render arrays instead of from Twig templates.

Nobody can predict the future. Not only SDC (actually BEM) enthusiasts.
And so let's use the only thing we have for now. Until, of course, the best came along.

So I consider the current issue at least controversial.
And definitely at this stage we should not prohibit anything or limit the development of components in any way.

One more thing

Many templates will shine as SDC components because they are reusable well-defined UI objects: status-messages.html.twig, breadcrumb.html.twig, table.html.twig, image.html.twig, progress-bar.html.twig, pager.html.twig, menu.html.twig... Let's focus on them.

The listed things are not so much needed as components.
They are usually written once and do not often need to be changed within the same site.

Unlike Card, Teaser, Button, Grid and other workhorses of any site. And this is
node.html.twig, user.html.twig, field.html.twig, block.html.twig, views.html.twig

About Form API. We (UI Patterns people) are trying to integrate UI components (our own format until recently, the SDC format now) with Form API for years now, without success. It would be a dream to get rid of Form Elements and use a superset of SDC to build forms. Did you already have an idea about how to do it? We can discuss about this in a dedicated issue.

See also 📌 Compatibility between SDC and the Form API Active