Maintain history state through redirect

[rubber-duck-software]

Scenario:

• user is on /a
• user clicks a link to /b with state { foo: 'bar' }
• loader for /b redirects to /c

Whatever state was passed with the link from /a to /b is lost and replaced with { _isRedirect: true }. Instead of replacing the supplied state with { _isRedirect: true }, I propose adding { _previousState: ... } to the supplied state, so in the scenario above you end with { _isRedirect: true, _previousState: { foo: 'bar' } }

Real world example:

Background

In my app, I am very carefully managing history with appropriate usage of replace to ensure the user doesn't go "back" to things like a modal route.
For our app if a users navigation is

• start at list view
• go to detail view
• open modal
• close modal
  then we expect the back button to take the user back to the list view, not re-open the modal.

Solution: both opening the modal and closing the modal are done with replace to ensure correct history

Location State Problem

Let's say that when the user went from the list view to the detail view, we passed along some location state. We want this location state preserved as we open/close the modal. The trouble is, if the modal closes via server side redirect, we cannot preserve the location state! It is replaced with { _isRedirect: true }.

Have other people dealt with this issue another way? Anyone else have apps where managing the history stack well is really important?

[rubber-duck-software]

I imagine the implementation to this would look something like #11275 (though honestly this is my first time looking at the implementation of this project)

[brophdawg11]

My initial gut reaction here is that this would be solved by providing state to loader functions. That would allow you to incorporate any preserved state into your redirect URL. Because state is also serializable we could potentially send it to the Remix server loader as well.

You might be able to test this flow today by directly accessing window.history.state.usr directly in your loader. This is a private implementation detail of React Router so this isn't a production solution - but it would let you see if having access to the current location state prior to the redirect would solve your use case, and if that's sufficient we could close this in favor of the other proposal.

[brophdawg11]

👍 Solution 2 is what I was referencing above, and I think a natural next step of the linked proposal (and cleaner than a __previousState approach)

I think if we exposed state to loader functions as suggested in the linked proposal we could add a way to proxy that along through redirect() as well.

[codeart1st]

I also have this problem right now and solution 2 looks good for me.

[JackSharpe94]

same, anyone got any sort of workaround to this?

[maxchan23]

could we get an update on this? I also encountered this predicament

[JavierLopezSCG]

had a similar use case.. any workarounds so far?