-
-
Notifications
You must be signed in to change notification settings - Fork 2k
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
fix: do not create unwanted record in history when redirecting after an invalidation #11895
fix: do not create unwanted record in history when redirecting after an invalidation #11895
Conversation
🦋 Changeset detectedLatest commit: 0a07b1f The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
return _goto(new URL(navigation_result.location, current.url).href, {}, 1, nav_token); | ||
return _goto( | ||
new URL(navigation_result.location, current.url).href, | ||
{ replaceState: true }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if this is right. If the result is a redirect, we do want to create a history entry for the redirect. Can you can explain why you've made this change here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, you don't want to create a history entry, because
- on server redirect (302) history entry is not created, and, IMO, client side and server side navigation should be consistent
- when you create history entry on client redirect, you create a loop in history. I mean, for example, if you press "go back" button in your browser, browser navigates to the "redirect" entry, which instantly goes forward again, so you essentially become stuck in a loop. With server redirects such loops cannot be achieved, and neither should they be achieved on the client side
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. So we want the intermediate navigations to not create history entries. Is that correct? But the final navigation should still create a history entry?
closing this as the issue #11896 (comment) has been closed as well |
Closes #11896
Please don't delete this checklist! Before submitting the PR, please make sure you do the following:
Tests
pnpm test
and lint the project withpnpm lint
andpnpm check
Changesets
pnpm changeset
and following the prompts. Changesets that add features should beminor
and those that fix bugs should bepatch
. Please prefix changeset messages withfeat:
,fix:
, orchore:
.Edits