[meta] Theme System Modernization Initiative

This is great! I really appreciate this pragmatic approach to work towards the #components goal in increments, the beauty is that even without that, these steps totally make sense.

So it looks to me that the next real step for those of us currently using a components theming approach* depends on the following two issues:

• #2818121: Create render array generator that can be used in Twig
• #2809689: Move hook_theme implementations into yml

But I don't think there's an easy way to get #2809689 into the components module, so we're stuck until 8.3. Still, exciting stuff. It'd be nice to simply add components with a drupal-specific yaml file in their directory and call them in a presenter template with a theme call.

Thanks again @lauriii for putting this together!

* Either using twig include + blocks or twig include + some sort of pre-render

#4: #2809689: Move hook_theme implementations into yml while you can't _move_ things, we could as first step _allow_ to define hook_theme implementations in YML and yes that could start easily within the components module.

So there is not a need to wait for core on that.

Is there a reason this is not in the idea issue queue? Just curious.

#6: It is not an idea, but several small concrete actionable issues we have been talking about for years.

At best it belongs to the components initiative (in a way) as it lays some groundwork for it. But components is frozen right now. Also some of this issues are implemented and prototyped in contrib first.

But all the changes / tasks are way within the scope of the theme subsystem, so this should indeed be sufficient.

Also there is no sign-off needed for the whole concept as again this is not a whole initiative, but rather some tasks that make each in themselves sense and are independent.

I feel that is the biggest difference.

Coming here from another issue - creating render arrays in the Twig template seems like an anti-pattern and I don't even see why we'd support it. Perhaps I'm not understanding the intended feature.

This is less problematic if it's only for specific render elements and the allowed keys can be validated.

What I don't want to support is actually writing render arrays directly as arrays in Twig since we may need to block that to resolve #2860607: Code execution via Twig templates (including inline)

@pwolanin I think you may be intending to comment on #2818121: Create render array generator that can be used in Twig.

This work is being informed by 2702061: Unify & simplify render & theme system: component-based rendering (enables pattern library, style guides, interface previews, client-side re-rendering) and is attempting to solve the pipeline issues currently present when attempting to integrate a Twig Component library with a Drupal theme and backend.

As I understand it, the plan is to eventually move away from render arrays, and instead focus on experimenting with the "best" ways to get Drupal backend data (which may be organized completely differently from the frontend structure) into a component frontend. For now though, we are building these experiments in Contrib modules on Drupal.org with the idea that a solid implementation will eventually evolve and be ready to include in Drupal 8 Core.

Adding related issue for visibility. I a bit confused by the different efforts going on in this area of Drupal...

This has stagnated, tremendously.

The IS needs to be updated and reorganized.

The IS needs to ultimately be reformatted matching: https://www.drupal.org/core/initiative-proposal-template

I would like to make this an official initiative.

Should we move this issue to the ideas queue to make for easier to coordinate this initiative?