Closed chris48s closed 4 years ago
Just thinking about this 6 months later, as you do...
I've recently worked with react-router on a couple of other projects and decided it is a poor fit in this situation.
Because we're embedded in someone else's site, there's a danger that if they are using some client side routing solution or relying on #anchor-links
, there is a risk of conflicts between our routing and the parent site's routing. This creates scope for a variety of spurious bugs to manifest e.g:
Because we need to work embedded in lots of different contexts we have no contol over, this is going to be a bad plan.
I reckon if we're going to do anything with pushing hashes into the URL, we shouldn't use a full routing solution and shouldn't attempt to read from the URL to infer state. It might be safe to look at doing a pushState()
on certain events if there isn't already a # in the URL, but I'd want to do some testing on that while embedded in some reaslitic parent environments before commiting to that.
I think we've settled on not doing this for the reasons above. The in-app "back to postcode search" button is the right solution.
This is likely possible with our current setup, but most resources I can find recommend using React-router and its history API. Will need a bit of digging.
https://stackoverflow.com/questions/39342195/intercept-handle-browsers-back-button-in-react-router