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.

[JavierLopezSCG]

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

[HriBB]

I might be waaay off here, bit couldn't you simply put the state into URL as URLSearchParams?

[skovhus]

We (linear.app) have ended up patching React Router's startRedirectNavigation function to support preserving the current state when throwing a redirect/replace from a data loader – currently by parsing a custom header. A native construct would be great.

@brophdawg11 I'm happy to contribute to this or discuss the API.

[gustavopch]

@skovhus If you're patching locally in your node_modules, you may want to give an upvote here to make patching easier: #13076

[skovhus]

PR up: #13205