While the presently accepted answer (storing the state in localStorage) can get the job done, I hesitate to advise doing it as it breaks a lot of patterns. You will now be driving state management partially outside of the React ecosystem, violating the state machine pattern and making your app dependent on an external global variable. So long as it is only a cache and only being accessed and set in this one location, it won't be the worst sin, but you never know when you'll have a developer come by and think "oh hey, I have this state being stored in localStorage, I'll just grab it that way," and then you're in for some trouble.
Instead, I'd suggest one of the following:
Storing the state in a parent component that isn't unmounting and giving access to the data and the state setter to your relevant component through props.
Setting up a context provider for the state, storing it there, and then subscribing to that context where you need it with the useState hook or a context consumer.
Each approach as some cons, for example, with the first option you'll need to do more prop drilling and you'll be storing state at a level of abstraction that isn't directly concerned with it, while in the latter case using a context might be a bit heavy-weight if you're only using the state in one place or one component-layer deep, but I'll leave it up to you to judge which approach is simpler for your use case.
Either one will keep all of your state management within the React ecosystem and avoid any pattern violations by yourself or future developers who don't understand the present rationale.