fix(qwik-city): add explicit magic attr to select Link for SPA resume #6022
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
👷 Deploy request for qwik-insights pending review.Visit the deploys page to approve it
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Overview
Simple/partial fix for this issue: #5983
Resuming SPA after context loss with refresh/reload requires a Link on the page or it falls back to location.href on popstate, it initially relied on a Qwik-internal key attached to Links. My impression of upcoming v2 changes is that this might disappear.
Either way this PR fixes this potential problem simply by adding a magic attr explicitly and selecting on that instead.
I also removed the erroneous
link:appattribute, this was added in thesync$commit, as a check whether the Link was same-app or foreign, but this check got replaced in another PR with a better impl to just not attach the sync$ handler at all if it wasn't. There was no reason for it to exist at this point. Its presence in the API also seemed to be a workaround for linting complaining about it being onlinkPropswithout being documented, this API didn't actually do anything at all, needless to say this was removed as well.