[TwigComponent] Support passing blocks to nested embedded components

[sneakyvv]

Q	A
Bug fix?	yes
New feature?	no
Tickets	Fix #844
License	MIT

The fix for #844, and a better solution then a manual passthrough workaround, is literally just passing the blocks from the "host Template" to the embedded Template, so that the blocks are merged with the embedded template's blocks, overriding them but altering their name and using a special outerBloocks variable to map the block name to the new name (see #920 (comment)).

This means that the example from #844 (comment) (tweaked a bit)

{# anywhere #}
{% set name = 'Fabien' %}
<twig:DivComponent>
    Hello {{ name }}!
</twig:DivComponent>

{# DivComponent.html.twig #}
<twig:GenericElement element="div" class="divComponent">
    {{ block(outerBlocks.content) }}
</twig:GenericElement>

{# GenericElement.html.twig #}
<{{ element }}{{ attributes }}>
  {%- block content -%}{%- endblock -%}
</{{ element }}>

Results in

<div class="divComponent">Hello Fabien!</div>

See the tests for more elaborate examples showing the access to context variables, multi-level overrides, etc.

[sneakyvv]

Note that I had some tests locally to address the ability to access the host/parent component from within an (nested) embedded component, but since that depends on #863 I didn't add them in this PR.
I'll add those tests either in that PR or in this one, depending on which one might get merged first.

[sneakyvv]

To fix the failing tests #918 should be merged. Done, and rebased

[sneakyvv]

For the record: as discussed on Slack, this PR currently can cause a recursive loop when a block (for example content) for a component has a(nother) component which also has a content block. The last component will be used in the actual content block for the first component. Then when the latter component is rendered it also will be using that same content definition from the first component. So it will render that first content block which renders the last's content blocks which refers again to the first and so on...

I have a fix for this ready, and will update the PR soon after I've updated/extended the tests.

[sneakyvv]

I pushed an improved mechanism to pass blocks down to nested components.

As said in my previous comment, just passing along blocks to the embedded templates will quickly end up in recursive loops, not using the correct blocks etc.

Now, blocks are still passed along but their name is being randomized.
A BlockStack object is introduced which keeps track of the location of a block definition, the relation to each embedded component, and that randomized name, so that when the component instance is rendered, the correct block definition can be accessed via the special outerBlocks variable (which refers to the BlockStack).

The example from the description now becomes (I've adjusted it there as well):

{# anywhere #}
{% set name = 'Fabien' %}
<twig:DivComponent>
    Hello {{ name }}!
</twig:DivComponent>

{# DivComponent.html.twig #}
<twig:GenericElement element="div" class="divComponent">
    {{ block(outerBlocks.content) }}
</twig:GenericElement>

{# GenericElement.html.twig #}
<{{ element }}{{ attributes }}>
  {%- block content -%}{%- endblock -%}
</{{ element }}>

I added a LOT more test cases, which deal with all kind of problems that would not be workable with just passing blocks down like:

• nesting the same component instances in each other, or simply components which are using the same block names
• skipping blocks for some component instances
• adding extra content to an outer block at some level of the component stack

See this test which lists all "rules" that blocks abide to within the context of embedded components.

[weaverryan]

This is QUITE impressive and also complex. You've done an excellent job annotating the complex code, but still, this is a BEAST. However, as this is important, the feature is experimental and its well-covered in tests, I think we need to merge it and try to start using it in the wild. Thank you for your hard work on this @sneakyvv!