Revalidating page when using browser's back button
Answered
Charmantle posted this in #help-forum
I'm currently working on a Google Docs/Notion clone as a project. The scenario in which this problem occurs is as follows:
1. The user starts at the Dashboard page, where they can see their list of boards/documents and dates for each board describing when it was last opened.
2. The user clicks on a board/document to go to its dynamic route
3. The user clicks on the browsers back arrow rather than the web app's dedicated Dashboard navigation button.
4. The user returns to the Dashboard, but "last opened" date is outdated and requires the user to perform a manual refresh.
If the user navigates back to the browser by means other than the back button, this problem does not arise. I've tried to utilize
I'm 99% sure that this is a caching problem. But I cannot think of any more ways to revalidate the cache on demand. I've tried converting the dashboard page into a client component to utilize the
Any other suggestions for what I could do to combat this issue?
I attached a picture of my Dashboard page code. I am also using Supabase for my ORM, but I don't think this should affect anything. Please let me know if you need any additional information, thanks!
1. The user starts at the Dashboard page, where they can see their list of boards/documents and dates for each board describing when it was last opened.
2. The user clicks on a board/document to go to its dynamic route
3. The user clicks on the browsers back arrow rather than the web app's dedicated Dashboard navigation button.
4. The user returns to the Dashboard, but "last opened" date is outdated and requires the user to perform a manual refresh.
If the user navigates back to the browser by means other than the back button, this problem does not arise. I've tried to utilize
export const dynamic = 'force-dynamic' and export const revalidate = 0 to combat this issue, but it does not seem to make a difference. From what I've read online as well, there are plenty of other people who are not seeing success with these on-demand techniques.I'm 99% sure that this is a caching problem. But I cannot think of any more ways to revalidate the cache on demand. I've tried converting the dashboard page into a client component to utilize the
useEffect hook, but it requires me to perform state management with all of the boards/documents which is going to be a huge headache to implement, so I really rather not go down that route. Any other suggestions for what I could do to combat this issue?
I attached a picture of my Dashboard page code. I am also using Supabase for my ORM, but I don't think this should affect anything. Please let me know if you need any additional information, thanks!
Answered by LuisLl
Try that, I was thinking about a little client component that does router.refresh() on mount, and simply returns null. If you import it in your board/document pages it might work
29 Replies
@Blood cockle you can directly use the window.history browser history stack
hey, thanks for taking the time to respond!
im still a little confused though
im not totally sure how i can use this to solve my problem
Yes this is a caching issue. What’s your Next.js version? It’s important to consider since caching default behavior has changed between versions
This looks like you’re getting the old router data instead of the fresh one, when you navigate back and forward using the browser back/forward button Next.js router cache serves the previous page (outdated as you said) to deliver an immediate response.
What you can do is to purge the router cache data, to avoid having outdated snapshots of your pages and navigations always serve fresh data.
What you can do is to purge the router cache data, to avoid having outdated snapshots of your pages and navigations always serve fresh data.
@LuisLl Yes this is a caching issue. What’s your Next.js version? It’s important to consider since caching default behavior has changed between versions
I updated to the latest release (15.2.2 I believe?) just yesterday, but that has not solved the issue.
@LuisLl This looks like you’re getting the old router data instead of the fresh one, when you navigate back and forward using the browser back/forward button Next.js router cache serves the previous page (outdated as you said) to deliver an immediate response.
What you can do is to purge the router cache data, to avoid having outdated snapshots of your pages and navigations always serve fresh data.
Yep, this is my plan with revalidatePath. Ig now my problem is how to call that function, since it cannot be placed within a componentt
@Charmantle I updated to the latest release (15.2.2 I believe?) just yesterday, but that has not solved the issue.
Backward/forward navigation always re-uses the router cache snapshots for instant navigation and to maintain scrolling position, unless this data is purged via
And you’re right, where to call these functions is the issue
router.refresh() and revalidatePath() / revalidateTag().And you’re right, where to call these functions is the issue
Maybe I could try calling
router.refresh in a child client component?Do you perform any server action or route handler inside the board/document pages?
Yes, i havent implemented them yet but there will be server actions being performed
@Charmantle Maybe I could try calling `router.refresh` in a child client component?
Try that, I was thinking about a little client component that does router.refresh() on mount, and simply returns null. If you import it in your board/document pages it might work
Answer
Blood cockle
you can make your page revalidate itself on a timer
not a solution, but better than nothing
@Blood cockle you can make your page revalidate itself on a timer
It doesn’t work for back/forward button
Revalidation time it’s already set to 0
Blood cockle
staleTimes wouldnt help?
It works for hard (refreshing) and soft navigations (<Link> and router.push) but for browser back and forward navigation you’ll always get the router cache previous snapshot
Blood cockle
hm ok
@Blood cockle staleTimes wouldnt help?
Well staleTimes is experimental and as far as I know it’s set to 0 by default, he can try. But the docs say it [won’t prevent the back/forward default behavior](https://nextjs.org/docs/app/api-reference/config/next-config-js/staleTimes)
This doesn't change back/forward caching behavior to prevent layout shift and to prevent losing the browser scroll position.
The null client component worked haha. A bit of a silly way to fix the issue but it works 😄
thank you!
@Charmantle The null client component worked haha. A bit of a silly way to fix the issue but it works 😄
Yes lol silly workaround for silly Next.js behaviors that do not come with an easy way to opt out. Glad it worked 👍, in the future when you perform mutations on board/document pages in Server Actions or whatever, make sure to sure revalidate the dashboard. That’s the intended way to do it, it’s assumed your dashboard data won’t change drastically between back/forward navigations, and if data changes then you should’ve revalidated it anyway. I guess they’re trade off Next.js makes us take to have instant navigation
Makes sense. I was just worried about a specific edge case where the user happens to not perform any server actions and then use the browser buttons for navigation rather than the app-provided links
@Charmantle Makes sense. I was just worried about a specific edge case where the user happens to not perform any server actions and then use the browser buttons for navigation rather than the app-provided links
Yea but it’s not that often that the user expects something to have changed when clicking back button, if they clicked back button it’s because they want to return to what it was previously there.
If they “navigate” to dashboard page through actual provided links or the user is redirected there as the result of a mutation or whatever then they’re surely get the latest data since the page will be requested again, because it’s dynamic.
If they “navigate” to dashboard page through actual provided links or the user is redirected there as the result of a mutation or whatever then they’re surely get the latest data since the page will be requested again, because it’s dynamic.