[TwigComponent] Add variable to refer outer scope when rendering embedded components

[sneakyvv]

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

This PR's is an alternative approach to the problem stated in #863.

Due to the changes proposed in #920, which deals with passing blocks down to nested embedded components, I realized that just being able to access the host (or parent) component isn't sufficient if blocks can be passed down multiple levels deep (as already mentioned in #863 (comment)).

This PR adds a proxy object Hierarchy which allows this syntax:

Component.php

final class Component
{
    public function scream(int $screamHowHard = 1): string
    {
        return 'sf-ux rules' . str_repeat('!', $screamHowHard);
    }
}

{# component.html.twig #}

<twig:Foo :someProp="this.something(1)">
    {{ someProp }}
    {{ outerScope.this.something(3) }}
</twig:Foo>

{# Foo.html.twig #}

<div>{% block content %}{% endblock %}</div>

Resulting in

<div>
    sf-ux rules!
    sf-ux rules!!!
</div>

Adding another layer below Foo, would ask for something like

{# component.html.twig #}

<twig:Foo>
    {{ outerScope.outerScope.this.something(3) }}
</twig:Foo>

to still point to Foo's function.

---

Questions

There's also a ComputedPropertiesProxy object. Should we have a cached version of the Hierarchy proxy?

---

NOTE

This PR continues on the changes of #920, because having a hierarchy only makes sense if blocks can be passed down multiple times. So #920 may have to be merged first, but if needed, and the outerScope.this syntax is preferred over the syntax of #863, I could push my branch that starts of the main branch instead.

Edited: using outerScope variable now instead Hierarchy proxy

[Kocal]

IMO a child component should not have access to its parent.

[weaverryan]

IMO a child component should not have access to its parent.

Well... the tricky thing is that you ARE still kind of "inside" the parent template - i.e. you're inside component.html.twig and want to access the Component object... but you currently can't if you're coding inside the <twig:Foo> section of that template.

I'm not on one side or the other yet.

[sneakyvv]

Since #920 is merged now, I rebased this branch on the current HEAD.

[weaverryan]

Instead of this.parent (which requires us to use a wrapper Hierarchy object and magic methods), what about following our outerBlocks convention and adding an outerContext variable?

{{ outerContext.this.someProp }} 

[sneakyvv]

How would you refer this.parent.parent then?

[weaverryan]

outerContext.outerContext.this.someProp? I think this would naturally occur if we started adding the outerContext variable, right?

[sneakyvv]

Changed and using outerScope variable instead of outerContext as discussed via Slack.

[weaverryan]

This is looking good - big set of tests 👍

[weaverryan]

It might be slightly more clear to just have:

Suggested change

	Hello {{ name }} {# name = Bart #}
	Hello {{ name }} {# Hello Bart #}

Especially in the next example, where name = Fabien isn't actually quite right. But showing the printed result, I think, is clear.

[sneakyvv]

changed

[weaverryan]

Suggested change

	{{ message }} {{ outerScope.name }} {# message = 'Hello', name = Fabien #}
	{{ message }} {{ outerScope.name }} {# Hello Fabien #}

[sneakyvv]

changed

[weaverryan]

I'd delete this. It's true - but I think people might not understand what you mean, and will second guess themselves. Let's focus on showing them the tools they have.

[sneakyvv]

removed

[weaverryan]

Move this to the top of the new docs

[sneakyvv]

done

[weaverryan]

Thanks Bart!