useState always using initial value on route change

[DPCamino]

When moving back (or forward) in the history, I would like the component state to be the same as it was before the route change. I was under the impression it would remember (without resorting to something like a global store) because the initial value would only apply for the component's initial render. Am I mistaken?

[tannerlinsley]

It should. This is likely a bug. Can you send me a CodeSandBox?

…

On Nov 25, 2021, 8:49 PM -0700, Yak ***@***.***>, wrote: When moving back (or forward) in the history, I would like the component state to be the same as it was before the route change. I was under the impression it would remember (without resorting to something like a global store) because the initial value would only apply for the component's initial render. Am I mistaken? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[DPCamino]

@tannerlinsley FYI,
I also added the counter to your Basic example and the issue was the same (was curious if related to using hash history).
In both cases on 'browser back' the count reverts to initial value.

[DPCamino]

Sorry for the delay. Here is a CodeSandBox to display its behaviour - I noticed it in my app but I just forked your simple example and added a counter in PostsIndex().

This is using hash history:
https://codesandbox.io/s/recursing-wright-z43ud?file=/src/index.tsx

1. Click on Posts.
2. Increase counter (e.g., to 5)
3. Click on a post link
4. Click Back
5. It reverts to initial value

Perhaps this is related to using hash history?

[tannerlinsley]

Sorry, I think we misunderstood each other. In your example, the useState is being unmounted as you transition to the individual post view. It's not rendered any more, so it's memory is thrown away. This is how React works at a fundamental level. You are 100% correct that you cannot persist component state without some type of external storage (global store, server store, URL store).

Sorry it took me a bit to figure out what you were referring to.

[DPCamino]

Ah I see. Thanks for the confirmation.

[DPCamino]

@tannerlinsley
In terms of best practice or recommendation, if we don't have that many state variables we'd like to remember when a user hits the back button, URL search params are acceptable?

I'm also using your react-table, and what I was thinking is storing the current tab selection and perhaps which row was expanded - so maybe 3-4 state variables. I know I can do that using plain params or use JSURL, just wanted to get feedback if this is a reasonable alternative instead of going full out on Redux or something similar.

[tannerlinsley]

Yes I think that’s acceptable :)