feat: restore the originally-attempted route after a ProtectedRoute redirect - #1101
Merged
Junirezz merged 1 commit intoJul 29, 2026
Conversation
…edirect ProtectedRoute (Junirezz#1071, Junirezz#981) already redirects a disallowed role away from a guarded route and stashes the attempted path in location.state.from "so a future redirect target can restore it later" — but nothing ever read that state, so a user who tried /admin and later connected the admin wallet just stayed on the page they'd been bounced to instead of landing back on /admin. Add useRestoreGuardedRoute(role), called from App.tsx whenever role changes. It tries the stashed `from` path once per role transition: if the new role is allowed, the user lands where they originally tried to go; if not, ProtectedRoute guards it again (role hasn't changed, so the hook won't re-fire), avoiding a redirect loop. Related to Junirezz#1040, which duplicates Junirezz#981, already resolved by Junirezz#1071 for the role/nav/guard scaffolding this builds on.
|
@esthertitilayo-dev Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits. You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀 |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Summary
Closes #1040.
Heads up for reviewers: #1040's title is an exact duplicate of #981, resolved by #1071 — merged less than a day before this PR was opened. That PR built the whole role-aware nav/guard system (
roles.ts,ProtectedRoute, admin nav gating, docs, tests). This PR doesn't re-build any of that; it finishes one specific pieceProtectedRoute's own doc comment already promised but never delivered:Nothing ever consumed that
location.state.from. A guest bounced away from/adminwho later connected the admin wallet just stayed on/instead of landing back on/admin.Added
useRestoreGuardedRoute(role), called fromApp.tsxwheneverrolechanges. It tries the stashedfrompath once per role transition: if the new role is allowed, the user lands where they originally tried to go; if not,ProtectedRouteguards it again — sincerolehasn't changed, the hook won't re-fire, so there's no redirect loop. UpdatedROLE_BASED_NAVIGATION.mdto document the completed behavior.Test plan
useRestoreGuardedRoute.test.tsx(covers: no stashed path → no-op, role already allowed → restores immediately, role still disallowed → stays put without looping, role changes to allowed → restores)ProtectedRoute.test.tsxandroles.test.ts— still passing, no behavior change to existing guard logicnpx tsc -b— no new type errors (one pre-existing, unrelatedToastCenter.tsxerror present onmainbefore this change too)🤖 Generated with Claude Code