Skip to content

BatchActionController isn't passing default route attributes #1022

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

Open
quisse opened this issue Jul 25, 2023 · 11 comments · May be fixed by #2767
Open

BatchActionController isn't passing default route attributes #1022

quisse opened this issue Jul 25, 2023 · 11 comments · May be fixed by #2767

Comments

@quisse
Copy link

quisse commented Jul 25, 2023

Let's say we register the ux_live_component routes as following:

live_component:
    resource: '@LiveComponentBundle/config/routes.php'
    prefix: '/_components'
    defaults:
       _routeScope: ['storefront']
       _loginRequired: true 

When the \Symfony\UX\LiveComponent\Controller\BatchActionController::__invoke is invoking sub requests, it sets the only certain attributes. So that for example the _loginRequired and _routeScope defaults are skipped. I want to create a PR to address this issue but not sure where to look. As the defaults are added to the routes at compile time and the batchAction is invoking the requests directly so that the route matching (and default attributes logic) is skipped.

@kbond
Copy link
Member

kbond commented Jul 31, 2023

Hmm, yeah, I see the problem. We can't just do a simple attribute merge in BatchActionController::__invoke() - this breaks the request.

@quisse
Copy link
Author

quisse commented Jul 31, 2023

Indeed, that seems risky business. The best thing imo is to apply the defaults to the dispatched subrequests but I'm not sure how to get the defaults at runtime since the routes are compiled/cached.

@kbond
Copy link
Member

kbond commented Jul 31, 2023

Yeah, the defaults are there in the sub-request but so are a lot of other attributes (added by the subscriber). When merging, we do get the defaults but a bunch of others that break the request.

@carsonbot
Copy link

Thank you for this issue.
There has not been a lot of activity here for a while. Has this been resolved?

@carsonbot
Copy link

Could I get a reply or should I close this?

@carsonbot
Copy link

Hey,

I didn't hear anything so I'm going to close it. Feel free to comment if this is still relevant, I can always reopen!

@carsonbot
Copy link

Thank you for this issue.
There has not been a lot of activity here for a while. Has this been resolved?

@carsonbot
Copy link

Friendly reminder that this issue exists. If I don't hear anything I'll close this.

@carsonbot
Copy link

Hey,

I didn't hear anything so I'm going to close it. Feel free to comment if this is still relevant, I can always reopen!

@arrabiata-asanz
Copy link

I have a similar problem, in my case the _route param get overwritten in the ->duplicate function call:

https://github.com/symfony/ux-live-component/blob/1e6d04c89c00d9b6d30ea0d9636eb68f5015d02d/src/Controller/BatchActionController.php#L25

public function __invoke(Request $request, MountedComponent $_mounted_component, string $serviceId, array $actions): ?Response
    {
        foreach ($actions as $action) {
            $name = $action['name'] ?? throw new BadRequestHttpException('Invalid JSON');

            $subRequest = $request->duplicate(attributes: [
                '_controller' => [$serviceId, $name],
                '_component_action_args' => $action['args'] ?? [],
                '_mounted_component' => $_mounted_component,
                '_live_component' => $serviceId,
            ]);

            $response = $this->kernel->handle($subRequest, HttpKernelInterface::SUB_REQUEST, false);

            if ($response->isRedirection()) {
                return $response;
            }
        }

        return null;
    }

what i did is i added this to the subRequest Attributes: the original _route param which should be ux_live_component -> '_route' => $request->attributes->get('_route'),.

I can provide a PR if nobody sees a problem 😄

@carsonbot carsonbot removed the Stalled label May 23, 2025
@kbond
Copy link
Member

kbond commented May 23, 2025

@arrabiata-asanz sure, I've lost the context a bit here but a PR would be great!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants