[LiveComponent] Bugfix #1509 - Adjust sequence of operations in the resetForm function

[jpvdw86]

Q	A
Bug fix?	yes
New feature?	no
Issues	Fix #1509
License	MIT

I have adjusted the sequence of operations in the resetForm function. Previously, the variable "formView" was set to null first, followed by its reassignment using $this->getFormView(). This resulted in the form not being fully reset.

This caused issues with bulk requests. The second request of submitForm expects the form to be reset and $this->formView to be null. By rearranging the operations, I ensured that the form is properly reset before any subsequent operations like bulk requests

[smnandre]

Hey @jpvdw86 thanks for the PR !

Could you maybe add a test or two ?

[smnandre]

As you did not reset form view... form values are the existing ones, and no the new view one.. This seem to change things, no ?

[smnandre]

The documentation states

After submitting a form via an action, you might want to "reset" the form back to its initial state so you can use it again.

With your modification it seems to me this is not the case anymore.. or did I miss something ?

https://symfony.com/bundles/ux-live-component/current/index.html#resetting-the-form

[jpvdw86]

The documentation states

After submitting a form via an action, you might want to "reset" the form back to its initial state so you can use it again.

With your modification it seems to me this is not the case anymore.. or did I miss something ?

https://symfony.com/bundles/ux-live-component/current/index.html#resetting-the-form

Using resetForm is still required. However, prior to this adjustment, not everything was reset. Initially, the value is set to null and filled again two lines later. Therefore, resetting was ineffective. I just change the order in the reset function to ensures that it is truly reset and the values $this->form and $this->formView are null after resetting the form.

[smnandre]

What i mean is that this->formValues is no more resetted to its initial mounted values .. or did i miss something ?

[smnandre]

Could you create a small reproducer with bulk requests ? What i'm not sure to get is how bulk requests would interfer .. the component beeing non shared services, they should not receive multiple request, no ?

[WebMamba]

Humm there are something I don't understant! The bulk request are made on the javascript side. So when we bulk, Symfony handle different request, so the container is a new container, and so the form are reseted to? am I missing something?

[smnandre]

Humm there are something I don't understant! The bulk request are made on the javascript side. So when we bulk, Symfony handle different request, so the container is a new container, and so the form are reseted to? am I missing something?

There is a batchactioncontroller in livecomponent... but i did search in the docs and found nothing about it 🤷‍♂️

[jpvdw86]

Humm there are something I don't understant! The bulk request are made on the javascript side. So when we bulk, Symfony handle different request, so the container is a new container, and so the form are reseted to? am I missing something?

---

In livecomponents, there is a function that liveactions request are bundled together in a so-called batch request. This reduces the number of requests to the backend.

However, this results that only one HTTP request is send to the backend en to the batchController. The request is then placed into subkernel requests. Because these are not entirely new requests, they are handled within the same container instance, leading to some issues.

Upon further consideration, I realize that my suggested fix is not the real solution and that more attention should be paid to this functionality, perhaps exploring the option of being able to disable the batch request functionality.

BatchController:

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;
    }

[jpvdw86]

@smnandre @WebMamba
I reverted my previous code and have now made adjustments to the live controller JavaScript.

The problem occurs when the same action is executed, as all instances of it are added as action to pendingActions. However, when executing the same live action, only the last one is needed since it contains the most recent information.

With this adjustment, it checks if there is already an existing pending action. In that case, the existing one is updated instead of adding a new one.

This prevents unnecessary batch requests and resolves also the issue with the form.

[smnandre]

I don't see your updates now... only the yarn.lock seems to have been modified (compared to the base 2.x branch) ?

[jpvdw86]

I don't see your updates now... only the yarn.lock seems to have been modified (compared to the base 2.x branch) ?

There where reverted. Now my change is available

[barbieswimcrew]

Hey guys, I have the same problem... will this fix be merged one day? ❤️

[Kocal]

Status: Needs work

The PR needs to be rebased, conflicts to be resolved, tests are missing and yarn.lock changes must be reverted.

Thank you 🙏🏻

[smnandre]

i've extracted one bit of your work to open a smaller PR with --afaik-- no side effects.

#2553