-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
chore: apply state to history.state directly #11521
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
Conversation
The serialization capabilities of history.state are basically identical to those of devalue.stringify . As such, the indirection of saving the data in the session storage isn't necessary, which also saves 1kb compressed / 3kb uncompressed because of the no longer needed devalue functions
|
|
lgtm - though it's been awhile since I've touched the client-side router, so perhaps Rich should give it a look |
* feat: make client router treeshakeable This removes the `create_client` method in `client.js` in favor of having everything as exported functions at the top level. Slight rearrangements to make some things lazy or put it behind a `BROWSER ?` condition are necessary, but otherwise the code is almost completely untouched. This makes it even less likely we can ever unit test the client router, but I think that ship has sailed a long time ago and e2e tests are a much more robust and an outright better way to test this, so it's a non-issue. * changeset * fix PURE annotation positions * POC for potential solution: force deduplication of modules by appending a query string * refine embedded approach use an increasing id -> things are still cached, but dynamically, and Vite plays ball, too * hacking my way to victory * tweak * move whole startup logic into create_client * these can be private functions now * fix * Update packages/kit/src/runtime/client/start_embedded.js Co-authored-by: Ben McCann <[email protected]> * chore: apply state to history.state directly (#11521) * chore: apply state to history.state directly The serialization capabilities of history.state are basically identical to those of devalue.stringify . As such, the indirection of saving the data in the session storage isn't necessary, which also saves 1kb compressed / 3kb uncompressed because of the no longer needed devalue functions * Apply suggestions from code review --------- Co-authored-by: Rich Harris <[email protected]> * Reduce indirection in treeshakeable client (#11544) * reduce indirection * fix * tweak error messages * sigh --------- Co-authored-by: Rich Harris <[email protected]> * remove all the embedded hackery (#11545) * remove all the embedded hackery * ugh --------- Co-authored-by: Rich Harris <[email protected]> * reduce diff size --------- Co-authored-by: Rich Harris <[email protected]> Co-authored-by: Ben McCann <[email protected]> Co-authored-by: Rich Harris <[email protected]>
The serialization capabilities of history.state are basically identical to those of devalue.stringify . As such, the indirection of saving the data in the session storage isn't necessary, which also saves 1kb compressed / 3kb uncompressed because of the no longer needed devalue functions.
Merge target is #11340