Roadmap

[mjackson]

This issue is a high-level roadmap for all work that we intend to accomplish, grouped by release. The goal is to provide an expected release version for a given piece of work.

The goal is not to discuss specific release dates, though some of that may happen.

This list is by no means exhaustive and will change from time to time as new issues are opened and PRs are merged.

4.10

• Allow basename prefixes with special regex characters (hasBasename bugfix #544, Allow ? character in basename for browser history. #566)
• Ignore initial popstate in some older browsers (Fix history.listen triggered by initial page load on some old browsers #555)

4.11

• Fix hash history.createHref when <base> tag is present (Fix base tag hash history create href #578)
• Fix hash history.replace when <base> tag is present (Ignore <base href> in hash history replace #577)
• Fix empty search string when createHref is used with an object (Reset search with question mark value to the empty string #701)
• Use console.warn instead of console.error when same path is pushed using hash history (Make hash history "same path" warning use console.warn #488)

5.0

Fix some long-standing issues, update browser support level, and introduce a few major new features.

• Drop support for browsers that do not support pushState
• Stop decoding pathnames (Remove location pathname decoding #656)
• Add state to hash history (Add state to hash history #704)
• New history.block(onBlock) API, remove getUserConfirmation
• Remove deprecated CJS-style requires (i.e. require('history/*'))
• Remove deprecated ESM-style imports (i.e. import from 'history/*)
• Remove keyLength option from createBrowserHistory

5.x

• Add custom window option in createBrowserHistory and createHashHistory (createBrowserHistory with a specific window object #624)
• Deprecate createLocation and locationsAreEqual
• Deprecate basename in createBrowserHistory and createHashHistory
• Deprecate .. pathname resolution
• Deprecate history.length in createBrowserHistory and createHashHistory
• Rename history.goBack => history.back, history.goForward => history.forward
• Add history/browser and history/hash bundles for singleton instances

6.0

Focus on getting the library size down by removing unnecessary features.

• Remove createLocation and locationsAreEqual
• Remove basename in createBrowserHistory and createHashHistory
• Remove .. pathname resolution
• Remove history.length in createBrowserHistory and createHashHistory
• Remove history.goBack and history.goForward

[pshrmn]

Should blocking be removed in v5 or v6? If v5 removes blocking, then it wouldn't be compatible with RRv5 because of the <Prompt> component.

edit: To expand, my thinking was that we would treat v5 like a minor release with no new "features", just no encoding and any bug fixes. Then, React Router could release a patch with its history dependency set to ^4.9 || 5. The pared down v6 of history would then be used with RRv6.

[mjackson]

Excellent point, @pshrmn. We'll reserve the pared down version for v6. I have adjusted the version numbers to reflect this change.

[pshrmn]

For v6, one possible change is to merge the push and replace functions into a single method. The default behavior would be to act like a link, so if the provided to is the same as the current location, it would replace and if they are not the same, it would push.

This would get rid of the issue with pushing the same location resulting in two session entries as well as simplify the API.

history.navigate(to);
history.navigate(to, "PUSH");
history.navigate(to, "REPLACE");

I did this with my implementation and it looks like Ryan did a similar thing with reach. state is the big difference between the implementations; mine only allows state when to is an object, while with reach, to is always a string and the second argument is an options object for both state and the navigation type. I'm not sure what the best solution for history would be.

// hickory
history.navigate({ pathname: "/somewhere", state: { success: true } });

// reach
history.navigate("/somewhere", { state: { success: true } });

[ryanflorence]

I designed it the way I did in @reach/router because:

Usually you just want navigate('/somewhere').

But then you realize you want some state so I optimized for this really simple change:

- navigate('/somewhere')
+ navigate('/somewhere', { state: 42 })

Compared to this change:

- push("/somewhere")
+ push({ pathname: "/somewhere", state: 42 })

Or you realize you want to "replace" instead of "push" and so I optimized for that change as well:

- navigate('/somewhere')
+ navigate('/somewhere', { replace: true })

I also found I often wanted to replace or push based on some application state, which is really lovely:

navigate("/somewhere", { replace: middleOfCheckoutFlow })

Rather than an if / else block for "push" vs. "replace".

All that said, I do like the idea of 100% symmetry with navigate(props) and <Link {...props}/> with an object like { to, state?, replace? }, but I still prefer navigate(to, opts?), because to isn't optional, so giving it its own argument feels good to me.