Skip to content

[TwigComponent] Add provide() and inject() Twig functions#3512

Open
Kocal wants to merge 1 commit intosymfony:3.xfrom
Kocal:twig-components-add-provide-inject
Open

[TwigComponent] Add provide() and inject() Twig functions#3512
Kocal wants to merge 1 commit intosymfony:3.xfrom
Kocal:twig-components-add-provide-inject

Conversation

@Kocal
Copy link
Copy Markdown
Member

@Kocal Kocal commented May 1, 2026

Q A
Bug fix? no
New feature? yes
Deprecations? no
Documentation? yes
Issues Fix #2522
License MIT

Suggestion for #2522, with a behavior similar to Vue.js.

Some components from Toolkit kits could be improved with this feature (will do it in another PR)

@Kocal Kocal self-assigned this May 1, 2026
@carsonbot carsonbot added Documentation Improvements or additions to documentation Feature New Feature TwigComponent Status: Needs Review Needs to be reviewed labels May 1, 2026
@Kocal Kocal force-pushed the twig-components-add-provide-inject branch from 9111aac to 7196f67 Compare May 1, 2026 15:22
@seb-jean
Copy link
Copy Markdown
Contributor

seb-jean commented May 1, 2026

I will try to review it as soon as I have time, if possible.

@Kocal Kocal force-pushed the twig-components-add-provide-inject branch from 7196f67 to 2b5ddae Compare May 1, 2026 17:12
@Kocal Kocal force-pushed the twig-components-add-provide-inject branch from 2b5ddae to 3c173e4 Compare May 1, 2026 19:41
@Kocal Kocal requested a review from kbond May 1, 2026 19:41
public function getProvided(string $key): mixed
{
if (!$this->hasProvided($key)) {
throw new \InvalidArgumentException(\sprintf('No provided context for key "%s" found.', $key));
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this exception reachable because getProvided() is always preceded by hasProvided()?

- Namespace your keys (``'inputOtp.maxLength'``, ``'tabs.active'``) to avoid
collisions.
- Calling ``provide()`` outside a component template throws.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You don't mention the second argument of inject() in the documentation.


This complements :ref:`outerScope <embedded-components-outerScope>`, which
only exposes the immediate parent's local context.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You don't mention the "overwrite" behavior, but it's well tested :D.

@seb-jean
Copy link
Copy Markdown
Contributor

seb-jean commented May 2, 2026

You had proposed two syntaxes (#2522 (comment)):

I had a preference for React's syntax :D.

What made you lean more toward Vue.js syntax rather than React?


I tested with this example:

  • templates/components/Input.html.twig
  • templates/components/Fieldset/Description.html.twig
  • templates/components/Fieldset/Field.html.twig
  • templates/components/Fieldset/Label.html.twig
<twig:Fieldset:Field disabled> 
    <twig:Fieldset:Label>Full name</twig:Fieldset:Label> 
    <twig:Input name="full_name" /> 
    <twig:Fieldset:Description>If you have a tiger, we'd like to know about it.</twig:Fieldset:Description>
</twig:Fieldset:Field>

This is interesting because the Input component is a separate component of Fieldset, not even a sub-component compared to Label and Description.

It works well, I get the disabled prop on each element using provide() / inject().


The rendering of Twig functions on this page https://symfony.com/doc/current/reference/twig_reference.html is interesting. Perhaps the same could be done for inject() and provide().

@Kocal
Copy link
Copy Markdown
Member Author

Kocal commented May 3, 2026

Thanks for the reviews :)

What made you lean more toward Vue.js syntax rather than React?

For two main reasons:

  • The way you use one or more contexts in React is, in my opinion, an abomination. You have to nest components, and you quickly find yourself in React Context Hell
  • More generally, Twig components are cool, but if we can avoid overusing them in favor of more "native" and more efficient solutions (in this case, two Twig functions), that's great

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Documentation Improvements or additions to documentation Feature New Feature Status: Needs Review Needs to be reviewed TwigComponent

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[TwigComponent] Add aware tag

3 participants