[TwigComponent] Allow specifying which `template` to render in `component()` Twig function

[FluffyDiscord]

I have the same Twig component form that I need to render differently in two places. I can always use EventListener for PreRenderEvent to adjust the template based on some variable, but it would be nice to have it built in. (I think this could be a built in thing, please tell me otherwise)

I propose this syntax/change:

{{ component('MyComponent', {
    '_template': 'some_other_template.html.twig'
}) }}

Where _template would be path to a different template, just like you can do using PreRenderEvent::setTemplate().

Basically adding this event listener by default:

<?php

use Symfony\Component\EventDispatcher\Attribute\AsEventListener;
use Symfony\UX\TwigComponent\Event\PreRenderEvent;

#[AsEventListener(PreRenderEvent::class)]
class ChangeComponentTemplateEventListener
{
    public function __invoke(PreRenderEvent $event): void
    {
        if (array_key_exists('_template', $event->getVariables())) {
            $event->setTemplate($event->getVariables()['_template']);
        }
    }
}

[smnandre]

Something we could definitely explore in 3.0. But to be honest, I'd like to take it a step further.

---

The core issue we face today is that TwigComponent does too much -- or rather, it combines many features whose coexistence makes it difficult to implement the optimizations others are asking for, especially given Symfony's BC promise.

On top of that, TwigComponent currently hosts part of the LiveComponent logic.

That's perfectly understandable-- in fact, it's a testament to how many of the features users have asked for have been delivered over time. But it also means we now have a component system that spans a wide spectrum: from anonymous, ultra-light components (basically includes), to deeply nested runtime-driven components powered by Live. And those layers weren't necessarily designed to coexist from day one.

Looking ahead, we need to better serve both ends of the spectrum, those who want minimal overhead and maximum performance, and those who want advanced runtime behavior and customization.

After we release 3.0, I'd like to share a possible direction -- one I've been thinking about (and working on quite a bit late last year). It builds on what we've learned, but introduces clearer boundaries and a more structured foundation. The goal wouldn't be to remove features, but to better separate concerns and unlock new possibilities without compromising existing ones. It's just a proposal for discussion, and of course we'll see with the UX team, contributors, and users whether it makes sense — or if a different path would be more suitable.

[FluffyDiscord]

Looks like huge refactor is in the making. Hopefully it won't be painful 😉