-
-
Notifications
You must be signed in to change notification settings - Fork 273
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[TwigComponent] Remove @internal from ComponentFactory
#1842
Comments
I’m not sure to follow. What do you call « manually » ? And the worflow you describe (request / serialization / render) is already possible with … a controller ? Maybe could you illustrate what you’re trying/would like to do ? |
An example of the controller I'm talking about, I'm not sure it works. use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Annotation\Route;
use Symfony\Component\Serializer\Normalizer\AbstractNormalizer;
use Symfony\Component\Serializer\SerializerInterface;
use Symfony\UX\TwigComponent\ComponentFactory;
use Symfony\UX\TwigComponent\ComponentRenderer;
final class ComponentManualController
{
public function __construct(
private readonly ComponentFactory $componentFactory,
private readonly ComponentRenderer $renderer,
private readonly SerializerInterface $serializer,
) {
}
#[Route('/_component', name: 'component_example', methods: ['GET'])]
public function __invoke(Request $request): Response
{
$name = 'example';
$component = $this->componentFactory->get($name);
// or use another mapper
$this->serializer->deserialize($request->query->all(), $component::class, null, [
AbstractNormalizer::OBJECT_TO_POPULATE => $component,
]);
$metadata = $this->componentFactory->metadataFor($name);
$mount = $this->componentFactory->mountFromObject($component, [], $metadata);
return new Response($this->renderer->render($mount));
}
} |
I'm sorry but ... why do you need any component here ? The factory is used to handle name -> class, the "mounting" and the template... all thing you could do directly from your controller .. or am i missing something ? Maybe with a concrete illustration of what would be the "component_example" ? |
Very often there is a need to update a component on page via ajax or turbo stream. With the current API it is possible like this: use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Annotation\Route;
use Symfony\UX\TwigComponent\ComponentRendererInterface;
final class ExampleController
{
public function __construct(
private readonly ComponentRendererInterface $renderer
) {
}
#[Route('/_component/{foo}', name: 'component_example', methods: ['GET'])]
public function __invoke(string $foo): Response
{
return new Response($this->renderer->createAndRender('name_component', [
'foo' => $foo,
]));
}
} As components grow, this becomes a problem. But it is not possible to create a "universal" controller since the api is marked internal. Sample code above, you need create component, mapped request and render him.
Maybe should add |
ComponentRendererInterface is not internal, and so is an extension point you can use as you wish.
It's an opinion that i can ear, but do not share :)
LiveComponent have no problem with TwigComponent... it's probably more the opposite right now :)
TwigComponent are meant to be .... Twig component. So the entire worflow is currently designed, coded & optimized to be used from a template, with no knowledge of request, controllers, etc...
... whereas the main reason of the Form component is to map request data to the view and backward. The main reason to not add aditional extension point is to keep the component maintanable, and ensure it will work in the way it is supposed to (by calling render directly you bypass some event for instance). That's why i would personally not be in favor to expose any other contract than the existing ones. |
Sorry, If this were enough, I wouldn't open the request, right?
So, if someone wants to make a package similar to LiveComponent, should he use internal api TwigComponent?
This has nothing to do with what I wrote. Signature methods ok, I understand your position, but also interested in the opinions of other maintainers. |
I'll review this more thoroughly when I have some time but just wanted to make a note about our use of As a package matures and a valid use-case comes up to use a service/object that's marked internal in user-land, I have no issue removing. I feel twig components is at this stage now. |
Related #707
It should be possible to create a component manually. Usually it's a few steps:
serializer
or use libliary for mappingThe described workflow occurs in
LiveComponent
, the same functional should be forTwigComponent
The text was updated successfully, but these errors were encountered: