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.

[rubber-duck-software]

I'm on Remix 🎉 Which is awesome, but does make this problem a bit harder.

If I understand correctly, the mentioned proposal suggests adding the ability read history.state in a loader but not being able to write it. (Perhaps being able to write to history.state in a loader would be a good feature as well... it would certainly address my concern... 🤔)

The trouble I have with only reading history.state in the loader is I'd have to write the history.state somewhere (maybe a cookie?) and read it again on the client. But now I've opted out of useLocation().state altogether since I might be reading from a cookie. Having access to history.state in the loader would certainly help a bit (reduces the amount of code in user land needed to solve this), but perhaps doesn't go as far as it could towards making my use case ergonomic.

[brophdawg11]

read history.state in a loader but not being able to write it

Where are you proposing to write history state in the proposal? You're just providing read access to the prior state, no?

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.

[rubber-duck-software]

Sorry- I don't think I'm describing my end goal very clearly.

⭐️ Goal:

Enable components to access previous history state after a redirect.

There are two solutions which I can see right now

Solution 1: Pointer to previous state

Right now redirects replace history.state with { _isRedirect: true }. We could add an additional key on this _previousState which enables accessing the state prior to the redirect.

Accessing the previous history would then look like

export default function Component() {
    const location = useLocation()
    const myState = location.state && location.state['_isRedirect'] ? location.state['_previousState'] : location.state
}

Solution 2: Allow Reading/Writing to history.state in loaders/actions

If loaders/actions could read/write history.state, then each loader/action could decide what history.state should be after a redirect.

Accessing the previous history would then look like

// a.ts
export async function loader({ locationState }) {
    return redirect('./b', { locationState })
}

// b.ts
export default function Component() {
    const location = useLocation()
    const myState = location.state // is equal to previous state since that is what the redirect in `a.ts` wrote
}

Pros and Cons

Solution 1 would be easy to implement and release. Replacing the state with { _isRedirect: true } is undocumented behavior, so I don't believe any release notes, docs changes, minor version increase etc would be necessary. This solution could be merged in pretty short order. However, this solution is not general purpose. It solves a particular issue, but is not solving a whole class of issues.

Solution 2: My impression is that this would be pretty involved to implement (especially in Remix). This would have to be put on the roadmap. I'm not sure if there are other attributes remix is serializing with every request, but regardless accessing location.state on the server is quite a feature. The advantage of this approach is that it is almost certainly a generally useful capability.

[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.