[2.0.0-alpha3] Replace component() function by native Twig mechanisms?

Postponed because there is no clear solution now.

Jean: "We can override embed and include in Twig, but the props & slots are not easily available once they are transformed as variable in the Twig template."

Here is a starting point before reaching the problem of re-mapping props and slots from Twig Node to Drupal render array API.

And another issue is how to pass the render array to Twig for render throw `render_var`.

Time flies. We have other priorities for beta2

In a way, it is more or less what SDC is doing:

ComponentsTwigExtension is adding 2 twig functions:

• add_component_context which is adding the attribute Attribute object if missing
• validate_component_props which is executing the JSON schema validator

They are not supposed to be used by templates owner, there exists because ComponentNodeVisitor is printing those Twig functions on every template, which will be executed on rendering in this order:

1. attach_library
2. add_component_context
3. validate_component_props

In order to make the use of "template to template" Twig functions or tags (include and embed) more similar to the use of the Render API, leveraging the render element. For example, attach_library is used here because #attached is not executed.

Ok, i will give a try

First proposal for include: https://git.drupalcode.org/project/ui_patterns/-/merge_requests/262/diffs

It was the easy one. embed will be an harder challenge

pdureau → changed the visibility of the branch 3449653-only-twig-visitor to hidden.

pdureau → changed the visibility of the branch 3449653-only-twig-visitor to active.

Another branch, so another MR, with another proposal: https://git.drupalcode.org/project/ui_patterns/-/merge_requests/267

Instead of calling the render element from include function, include tag and embed tag, we stay closer to the current SDC implementation:

1. reorganize our Twig modules visitors to be run before and after the SDC one
2. move some logic from the render element to an internal Twig function run by one of the Twig modules visitors
3. promote include() function as a replacement of component() function

Why include() function? Because:

• include tag is not recommended by the Twig documentation: bhttps://twig.symfony.com/doc/3.x/tags/include.html
• as previously stated, embed tag is an overcomplicated, Twig specific, template altering mechanism which must be avoided at any cost

The crazy, ambitious, change is not forgotten and will be discusse din the Core issue: 📌 Trigger SDC render element when using Twig include or embed Active

I really like the new direction, because it will cope with current (bad) usages out in the wild and we will use a twig function instead of a custom twig function.

What i would expect in addition to this work, is a little bit of automatic testing. may i help with that maybe?

if you agree, i can continue the work in the MR and add new kernel tests.

yes, please, add the kernel tests because I never done such a thing

Yes that is the way! Right now we "only" normalize the prop values. Shouldn't we support full UI Patterns support like.

{% embed "module:component" with { 
  "ui_patterns": {
    props: {
        prop1: {
           value: value
        }
    }
  }
}

So we move the preparing logic from the element to twig. Not sure if it goes too but from an architectural point of view it is straight forward and opens new possibilities.

Hi Christian, it is great you like the change.

The data structure you are showing here is not compatible with the issue goal: being compatible with existing Twig mechanisms, to be compatible with the (kind of sad) state of existing SDC themes.

So, it must be this instead:

{% embed "module:component" with { 
        prop1: value
    } %}

Also, in your example, you used embed which is a Twig tag we are not promoting. Our change is compatible with all Twig mechanisms but we are promoting only include() function because:

• include tag is not recommended by the Twig documentation: bhttps://twig.symfony.com/doc/3.x/tags/include.html
• as previously stated, embed tag is an overcomplicated, Twig specific, template altering, mechanism which must be avoided at any cost

So, it must be this instead:

{{ include("module:component", { prop1: value }) %}

with a few tests now, let's merge this :D

Instead of adding this:

    if (!isset($context['attributes'])) {
      $context['attributes'] = [];
    }

I beleive this would be better to move here a few lines from ComponentElementAlter::

    // Attributes prop must never be empty, to avoid the processing of SDC's
    // ComponentsTwigExtension::mergeAdditionalRenderContext() which is adding
    // an Attribute PHP object before running the validator.
    $element["#props"]["attributes"]['data-component-id'] = $component->getPluginId();

pdureau → changed the visibility of the branch 3449653-only-twig-visitor to hidden.

pdureau → changed the visibility of the branch 3449653-only-twig-visitor to active.

Hi,

Possible to change a little bit the warning message to have "...function and will be removed before UI Patterns 2.0.0."?

The strong tag is not needed, only for this issue queue comment.