Async/sync location updates after history back/forward

Version

4.2.2

Steps to reproduce

If I understand correctly:

1. history.goBack delegates straight to the History API.
2. Immediately afterwards, window.location refers to the previous page.
3. When the popstate event is emitted (via history.listen), Route components will be updated with the new location prop (derived from the current window.location).

I have a modal component which calls history.goBack when it’s closed, just like the example here: https://reacttraining.com/react-router/web/example/modal-gallery.

My problem:

• Components may re-render themselves any number of times between history.goBack (1, above) being called and the popstate event being emitted (3).
• During these re-renders, the location prop will refer to the old location (the one prior to the history.goBack call).

This means the modal will remain mounted (because the current location is still the modal), and the user may try to close the modal again, resulting in another call to history.goBack.

1. user comes to our site (/) from another site (e.g. Google)
2. user clicks through to a modal location (/modal)
3. user closes modal. URL immediately updates (/), but old modal location remains (/modal; due to no popstate event yet), thus modal remains mounted
4. user tries to close modal again, and location reverts to Google (!)

I’m wondering if React Router should synchronously/immediately update route components with the new location after a call to history.go{Back,Forward}, rather than waiting for the popstate event (which is asynchronous). This should eliminate problems like the example I gave above.

(I’m also wondering why there is such a long delay between history.goBack and popstate—perhaps because we have a lot of other work to complete in the stack frame that history.goBack is called.)

(I’m hoping I haven’t misdiagnosed the problem here…)

[OliverJAsh]

@pshrmn Thanks, that is what I ended up doing, but since the official modal example follows the same approach, I thought about raising it as an issue.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.