-
Notifications
You must be signed in to change notification settings - Fork 961
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add state to hash history #704
Comments
I discussed this a bit with @mjackson a few months ago and I believe that a future version of |
Yes, but it will have to happen in a future major version. We need to bump our browser support to be only browsers that support |
Quick update here: we are planning on adding this feature in version 5. |
New features: - Remove legacy browser support (pre pushState) - Add state to hash history - Use custom window when creating history objects - Better history.block API (wip) - Fix location.pathname encoding issues - About 50% smaller - No dependencies Removed features: - Removes basename support - Removes getUserConfirmation - Removes keyLength - Removes hashType - Removes relative pathname support in hash + memory histories Still TBD: - Missing pathname support in push/replace Fixes #624 Fixes #704 Fixes #723 Fixes #726
Heads up: in the v5 beta released today you can now use state with hash history. Please give it a shot and LMK how it goes! |
I've tried updated our project with it, removing my own simple implementation we've had for the last few months - I can see the browser state working correctly. I've got a couple of issues but I think they're to do with relative paths so I think it's looking good 👍 Thanks for doing this! |
Pretty awesome this is finally happening guys! Even if it's after that project has long since ended and I don't do much React anymore :) (*reserves package name svelte-react-router) |
I'm currently in a similar position to that mentioned by @matthewrobb in #435, where I am limited to using the hash portion of the url for my dynamic application routing but I'm not limited in my support for older browsers and want to make use of storing state in the navigation whilst using hash urls.
I know #435 mentions a few workarounds to use
browserHistory
andbasename
but those workarounds feel like a bit of a hack and won't really work for me.I am going to be putting together my own version of hashHistory that uses the browser history API and I was wondering if there would be any interest in adding that within to this library. I'd be happy to submit a PR to do it, but would need a bit of guidance on what approach to take here and what would need to be supported.
The text was updated successfully, but these errors were encountered: