This PR was merged into the 3.x branch.
Discussion
----------
ChainLoader constructor should accept iterable instead of array
Closes#4200
Commits
-------
6ef13d1eResolves#4200
This PR was merged into the 3.x branch.
Discussion
----------
Swap BC layer for yield-ready and reclaim perf loss
Follows #3999Fix#4146Fix#4103
When `use_yield` is set to false (the default), this PR reverts the implementation of the `render()` method to use a wrapping output buffer instead of hooking between each steps of generators. In this mode, the behavior of the yield method is not "pure": it triggers a mix of yield and echo. But this is fine for render and display methods.
When `use_yield` is set to `true`, we skip that wrapping output buffer. This makes twig compatible with fibers (and this also makes compilation fail if a non-YieldReady extension is found.)
That makes the name of the option not ideal, but BC rulez FTW.
Commits
-------
5d1a19a8 Swap BC layer for yield-ready and reclaim perf loss
This PR was merged into the 3.x branch.
Discussion
----------
Accept colons instead of equals for named arguments
Refs #3475
Refs #3635
Commits
-------
84116e5f Fix typos in CHANGELOG
This PR was squashed before being merged into the 3.x branch.
Discussion
----------
Introduce CVA to html-extra
Hey! This PR introduces CVA to Twig. All of this has already been merged into SymfonyUX (https://github.com/symfony/ux/pull/1416), but `@kbond` suggested that this repo can be a better place for this feature.
Here is a description from the PR merged in to SymfonyUX:
------------------------------
This PR introduces a new concept CVA (Class Variance Authority), by adding a1 twig function, to help you manage your class in your component.
Let's take an example an Alert component. In your app, an alert can have a lot of different styles one for success, one for alert, one for warning, and different sizes, with icons or not... You need something that lets you completely change the style of your component without creating a new component, and without creating too much complexity in your template.
Here is the reason came CVA.
Your Alert component can now look like this:
```twig
{% props color = 'blue', size = 'md' %}
{% set alert = html_cva(
'alert rounded-lg',
{
color: {
blue: 'text-blue-800 bg-blue-50 dark:bg-gray-800 dark:text-blue-400',
red: 'text-red-800 bg-red-50 dark:bg-gray-800 dark:text-red-400',
green: 'text-green-800 bg-green-50 dark:bg-gray-800 dark:text-green-400',
yellow: 'text-yellow-800 bg-yellow-50 dark:bg-gray-800 dark:text-yellow-400',
},
size: {
sm: 'px-4 py-3 text-sm',
md: 'px-6 py-4 text-base',
lg: 'px-8 py-5 text-lg',
}
},
[{
color: ['red'],
size: ['lg'],
class: 'font-semibold'
}],
{
rounded: 'md'
}
}) %}
<div class="{{ cva.apply({color, size}, attribute.render('class'), 'flex p-4') }}">
...
</div>
```
So here you have a `cva` function that lets you define different variants of your component.
You can now use your component like this:
```twig
<twig:Alert color="red" size="md"/>
<twig:Alert color="green" size="sm"/>
<twig:Alert color="yellow" size="lg"/>
<twig:Alert color="red" size="md" class="dark:bg-gray-800"/>
```
And then you get the following result:
<img width="1269" alt="Capture d’écran 2024-01-24 à 00 52 33" src="https://github.com/symfony/ux/assets/32077734/6a5e25be-5b81-4ae7-8385-0fa5422d0396">
If you want to know more about the concept I implement here you can look at:
- CVA (js version): https://cva.style/docs
- tailwind merge: https://github.com/gehrisandro/tailwind-merge-php, https://github.com/dcastil/tailwind-merge
- this implementation by using tailwind-merge and cva is inspired a lot by: https://ui.shadcn.com/ (shadcn is the most starred library on github in 2023)
- a really good article that explains the philosophy behind https://manupa.dev/blog/anatomy-of-shadcn-ui
- this PR works great in a LASTstack: https://symfonycasts.com/screencast/last-stack/last-stack
Tell me what you think about it! Thanks for your time! Cheers 🧡
------------
Commits
-------
e3ac14e1 Introduce CVA to html-extra
This PR was squashed before being merged into the 4.x branch.
Discussion
----------
Add return types missed in #4211
Complete #4211 (sorry)
I forgot to update the docs, and found some others in RuntimeLoader(s)
Commits
-------
21f08dcf Add return types missed in #4211
This PR was squashed before being merged into the 4.x branch.
Discussion
----------
Add missing return types in 4.0
Revert the removal of return types done in #3156
Should i propagate to `extra` packages in the same PR ?
Commits
-------
470965fc Add missing return types in 4.0
This PR was merged into the 3.x branch.
Discussion
----------
Special functions extension point
The `parent`, `attribute`, `block` (and `loop` in 4.0) functions are handled directly in ExpressionParser as they are converted to specific Nodes.
It means that recursive loops can only be implemented in core. By adding a new extension point, we are removing the hardcoded handling of such functions and we open up the possibility for user-land functions to do the same.
*Review is easier when hiding whitespace.*
Commits
-------
44280790 Add an extension point for parsing special functions
This PR was merged into the 3.x branch.
Discussion
----------
Add support for named arguments on special functions
Commits
-------
0c30e78b Add support for named arguments on special functions
Fabien Potencier
Nikola Svitlica a.k.a TheCelavi
Nicolas Grekas
Vincent Langlet
Matheo Daninos
Simon André