[LiveComponent] Add the possibility to map LiveProp as a path parameter

[mbuliard]

Q	A
Bug fix?	no
New feature?	yes
Docs?	yes
Issues	No
License	MIT

The purpose of this MR is to give the responsability of changing the URL to the backend, allowing to use Symfony Router and to have LiveProps in the path, not only in query parameters :
http://example.com/content?id=123 vs
http://example.com/content/123

To set the LiveProp in the path, a new option, mapPath has been added to the UrlMapping option of the LiveProp :

#[LiveProp(writable: true, url: new UrlMapping(mapPath: true))]
public int $id;

WORKFLOW

1. When sending a request to the backend, the frontend add a new header X-Live-Url containing the current path and query parameters.
2. On KernelResponse event, the new path and query string is calculated from the header received and the new props and put in the response header X-Live-Url.
3. When the frontend receives the response, the current path and query are placed by those received, via history.replaceState.

BACKEND CHANGES

• New UrlFactory service to generate URL from the previous one, the path-mapped props and the query-mapped props. The url is first generated by the Symfony Router, using the previous one and the path-mapped props. Then the query-mapped props and the previous query parameters are added.
• QueryStringPropsExtractor is renamed to RequestPropsExtractor and now extract props from the request attributes and query parameters.
• UrlMapping now has a new option mapPath, boolean, false by default.
• LiveComponentMetadata has new method getAllUrlMappings returning urlMappings of all LiveProps.
• QueryStringInitializeSubscriber is renamed to RequestInitializeSubscriber
• new LiveUrlSubscriber, listening to KernelResponse, and setting the X-Live-Url of the response with the new URL, generated by the UrlFactory. To generate it, the previous location is extracted from the request and the props are extracted from metadata, hydrated with the values of _live_request_data and sorted between path-mapped and query-mapped.
• LiveComponentSubscriber now add responseProps data to the _live_request_data attribute, containing the mounted component data when the action is not the default one. This change is made to take server-side changes into account.
• LiveComponentMetadata has new method getAllUrlMappings returning urlMappings of all LiveProps.

FRONTEND CHANGES

• Backend/RequestBuilder now add the current pathname and search as X-Live-Url header in the request.
• Backend/BackendResponse has new property liveUrl, populated from the HTTP response X-Live-Url header.
• Component/index.ts : performRequest now check for X-Live-Url header in response and, when found, do history.replace with the new url and the current hash and origin.
• url_utils is removed.
• Component/plugins/QueryStringPlugin is removed.

TODO

Review :-)

[github-actions]

📊 Packages dist files size difference

ℹ️ No difference in dist packagesFiles.

[smnandre]

(Had a quick chat with @mbuliard yesterday — he's making a few adjustments before opening the PR. Stay tuned! 😄 )

[smnandre]

Do you want/need any help here @mbuliard ?

[mbuliard]

Do you want/need any help here @mbuliard ?

Thanks ! I needed free time, but the PR is almost done. Related tests are green, but I shall now add my own testing of the backend.

What took me some time was to the handling of custom actions, who may (and often do) update component props. I choose to store the updated component props in _live_request_data.responseProps, next to props and updated values.
I'm thinking to always populate these responseProps, even for default action and then simplifying my LiveUrlSubscriber.

[Kocal]

Suggested change

	$newUrl = null;
	if ($previousLocation = $request->headers->get(self::URL_HEADER)) {
	$liveProps = $this->getLivePropsToMap($request);
	$newUrl = $this->urlFactory->createFromPreviousAndProps($previousLocation, $liveProps['path'], $liveProps['query']);
	}
	if ($newUrl) {
	$event->getResponse()->headers->set(self::URL_HEADER, $newUrl);
	}
	if ($previousLiveUrl = $request->headers->get(self::URL_HEADER)) {
	$liveProps = $this->getLivePropsToMap($request);
	$newLiveUrl = $this->urlFactory->createFromPreviousAndProps($previousLiveUrl, $liveProps['path'], $liveProps['query']);
	$event->getResponse()->headers->set(self::URL_HEADER, $newUrl);
	}

[mbuliard]

I kept two separated if to not set the header if the $newLiveUrl is null.
It can happen if :

• the previous url cannot be parsed
• the previous url does not match any known route
• some mandatory parameter is missing to generate the url of the route

But maybe it would be better to throw exceptions ?
I was worried to break anything doing so

[smnandre]

Can you rebase (a last time i hope) @mbuliard ?

Is that ok for you @Kocal ? Anything else to check ?

[kbond]

Looks good! The docs are much clearer.

[Kocal]

It took time, but here we go, this is in now. Thank you very much @mbuliard.