This was a request from @bnjmnm during a meeting today to discuss committing SDC to core.
We want to investigate augmenting usage of include/embed with custom Twig function. This would have the benefit of not passing in context (similar to Twig's only keyword).
I think this leaves us with a custom function as our only option if we want to do this. However, I am increasingly convinced that we might now want to do this. The reason being documentation of the new method, and catching up with new features and bugfixes.
Comments
Comment #2
e0ipsowith_context. Which is desirable for components.{% block foo %}which complicates support for slots.include/embedComment #3
jonathanshawI think it should be possible to enforce
with_contextto befalsewhen usinginclude/embedwith a component, using a Twig NodeVisitor.For those innocent souls who have not yet encountered the unholy mystery that is Twig's NodeVisitors, see
lib/Drupal/Core/Template/TwigNodeVisitor.phpfor an example of how Drupal is already altering the functionality of Twig's provided functions.Comment #4
jonathanshawComment #6
e0ipsoComment #7
e0ipsoAnother idea is to add a warning during development (in a similar fashion we use for validation errors). This warning could show a message in the page whenever a component is put in the page without the
onlykeyword. This check should probably happen in the same node visitor we use for attaching the library to the page, like @jonathanshaw suggests.Comment #8
e0ipsoDoing this in the
includeandembedwill be a backwards compatibility break. Since SDC is beta experimental, we need to maintain BC. Additionally, this would be a departure from the expectations thatincludeandembedwork the same way as described in Twig's documentation.Comment #9
jonathanshawAs a version of #7, it should be possible to detect and warn in a node visitor if a variable that is not a defined slot/prop is used inside a component.
We now do something very similar to this to detect usage of deprecated variables, allowing us to deprecate variables passed to twig templates.
This would allow us to continue to use include/embed, with the documented behavior developers expect.
Comment #10
dieterholvoet commentedComment #11
brayn7 commentedI have encountered this issue in tandem with https://www.drupal.org/project/drupal/issues/3464719. If the only keyword is forced that would be good but we gotta make sure blocks from embed still get passed down and not blocked. Let me know if I need to post an example. I find myself needing to pass down a block for an embed to a nested embed block basically. Maybe thats bad practice. let me know. Cheers.
Comment #12
brayn7 commentedHere is something I am curious what others are doing.
Backstory, I was originally passing most things as properties to an include when @Pierre (pdureau) pointed out it would be better to use slots for most things and prevent prop drilling of sorts. I think this is a great idea and I am on the path to solving it and wrapping my head around it completely and refactoring as we go. Here is what I am coming across:
Property context may get contaminated when not using ONLY or with_context:false.
When using ONLY or with_context: TRUE I am blocked from passing a content.field_item to a embed block.
What is everyone doing in this situation?
Here is what I thought of as a workaround for the time being maybe
Comment #13
nicolasgraph@brayn7, I also do the same, or kind of, using a fake "slots" prop to store an associative array of variables needed in slots.