symfony
[TwigComponent] Fix InteractsWithTwigComponents not being able to render blocks when variable scope is limited
| Q | A |
|---|---|
| Bug fix? | yes |
| New feature? | no |
| Deprecations? | no |
| Documentation? | no |
| Issues | Fix #3210, Fix https://github.com/symfony/ux/issues/3216 |
| License | MIT |
When using Blocks, the helper for rendering Twig Components in tests (InteractsWithTwigComponents::renderTwigComponent) would create a template like this:
{% component "My:Component" with data %}{% block myBlock %}{{ blocks.myBlock|raw }}{% endblock %}{% endcomponent %}
Passing the variables data and blocks from outside, where blocks contains the block content indexed by block name.
If the block however was declared inside a {% with … only %} scope, this would not work, because inside the block, you wouldn't have access to blocks.
This PR fixes the issue by inlining the block content when creating the template.
This probably means that the template cache creates new entries whenever the block content changes. But I think this is tolerable.
This probably means that the template cache creates new entries whenever the block content changes. I assume that in most cases, the block content will only change when the Test code changes. Is this tolerable?
Alternatively, I could imagine fixing this by calling outerScope.blocks instead of blocks in the generated template – this would still require Twig Component authors to allow the outerScope variable in blocks they want to test, but at least, outerScope is not a name internal to the test helper.
This is problematic to me, as using outerScope really does change the runtime code and makes it in my eyes too different of what would happen in production. Also at best it would not bring added value for most users.. at worst it could be causing problems with outerScope or any change we do around its implementation.
I'm pretty sure we can find a way to help you in that very specific need without impacting every other tests out there ..
--
Update: comment originally written for the PR with your other implementation idea, but still valid (not for the outerscope runtime, but the cache one indeed is a big change, has even the lines in the template would change, its hash, etc..)
