Description
Applying filters/sort/page on a dashboard list (Opportunities, Volunteers, Agents), then using the browser's back button, doesn't return to that filtered list state. Instead it jumps past it, landing on whatever page was open before the list was ever visited (e.g. the dashboard Home). Expected: back should return to the last list state the user was actually looking at.
Confirmed contributing cause
All three dashboard list pages share the same pattern:
Opportunities.tsx, Volunteers.tsx, and Agents.tsx each have a useEffect that syncs filter/sort/view-mode state to the URL via router.replace(...), not router.push.
- Pagination (
usePageParam.ts) does the same, router.replace on page change.
- The ONE
router.push in the flow is the initial sidebar navigation into the list (NavigationBar.tsx, router.push(route)).
Net effect: no matter how much filtering/sorting/paging a user does on a list, the entire visit is a single browser-history entry (the URL just gets rewritten in place each time via replace). So one press of "back" pops that single entry and returns straight to whichever page preceded the list visit, skipping over the filtered state itself rather than "un-filtering" one step at a time.
Not a regression of the closed filter-persistence issues
#356, #487, and #729 (all closed) fixed a different, related problem: filters/pagination/sort resetting when navigating from a list to a Profile page and back. Those were fixed by moving that state into URL params in the first place. That fix is working as intended and is not what's reported here, this is a distinct, previously-unaddressed side effect of using replace for all of those URL updates: it solves "state survives a remount" but does nothing for "back button should step back through what I was actually browsing."
Ask
Confirm the exact repro path (which page you're on when you hit back, and what "generic homepage" is, /dashboard Home, or the public site) and fix so back returns to the filtered list state rather than skipping it. Likely fix shapes to weigh: pushing one history entry when a user first lands on a list with an unfiltered URL vs. a filtered one, or intercepting back navigation to restore the last list URL explicitly, rather than relying on native multi-step history through replace-only updates.
Description
Applying filters/sort/page on a dashboard list (Opportunities, Volunteers, Agents), then using the browser's back button, doesn't return to that filtered list state. Instead it jumps past it, landing on whatever page was open before the list was ever visited (e.g. the dashboard Home). Expected: back should return to the last list state the user was actually looking at.
Confirmed contributing cause
All three dashboard list pages share the same pattern:
Opportunities.tsx,Volunteers.tsx, andAgents.tsxeach have auseEffectthat syncs filter/sort/view-mode state to the URL viarouter.replace(...), notrouter.push.usePageParam.ts) does the same,router.replaceon page change.router.pushin the flow is the initial sidebar navigation into the list (NavigationBar.tsx,router.push(route)).Net effect: no matter how much filtering/sorting/paging a user does on a list, the entire visit is a single browser-history entry (the URL just gets rewritten in place each time via
replace). So one press of "back" pops that single entry and returns straight to whichever page preceded the list visit, skipping over the filtered state itself rather than "un-filtering" one step at a time.Not a regression of the closed filter-persistence issues
#356, #487, and #729 (all closed) fixed a different, related problem: filters/pagination/sort resetting when navigating from a list to a Profile page and back. Those were fixed by moving that state into URL params in the first place. That fix is working as intended and is not what's reported here, this is a distinct, previously-unaddressed side effect of using
replacefor all of those URL updates: it solves "state survives a remount" but does nothing for "back button should step back through what I was actually browsing."Ask
Confirm the exact repro path (which page you're on when you hit back, and what "generic homepage" is,
/dashboardHome, or the public site) and fix so back returns to the filtered list state rather than skipping it. Likely fix shapes to weigh: pushing one history entry when a user first lands on a list with an unfiltered URL vs. a filtered one, or intercepting back navigation to restore the last list URL explicitly, rather than relying on native multi-step history throughreplace-only updates.