[WIP] LiveUrl

[mbuliard]

Q	A
Bug fix?	no
New feature?	yes/no
Docs?	yes/no
Issues	Fix #...
License	MIT

WIP, DO NOT MERGE

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.
• 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. TODO tests
• 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. TODO tests

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

• Complete tests
• Changelog
• Docs

[github-actions]

📊 Packages dist files size difference

Thanks for the PR! Here is the difference in size of the packages dist files between the base branch and the PR.
Please review the changes and make sure they are expected.

File	Before (Size / Gzip)	After (Size / Gzip)
LiveComponent
Backend/BackendResponse.d.ts	136 B / 139 B	199 B+46% 📈 / 163 B+17% 📈
Component/plugins/QueryStringPlugin.d.ts	356 B / 239 B	Removed
live_controller.d.ts	3.3 kB / 924 B	3.1 kB-6% 📉 / 893 B-3% 📉
live_controller.js	120 kB / 23.4 kB	116.68 kB-3% 📉 / 22.57 kB-4% 📉
url_utils.d.ts	306 B / 205 B	Removed

[smnandre]

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

[smnandre]

Suggested change

	HistoryStrategy.replace(new UrlUtils(liveUrl + window.location.hash, window.location.origin));
	history.replaceState(history.state, '', liveUrl + window.location.hash);

? (not sure)

[smnandre]

This would allow the remove both queryStringPlugin.ts and url_utils.ts (i think)

[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.