[META] v3.0.0

[taion]

I'm setting this up as a meta-issue instead of a milestone to allow for more commentary and discussion. I'm going to close the originating issues and fold them into here for now, so we have a single issue on which to track things.

We're looking to cut a v3.0.0 soon, starting with PRs, to update dependencies, clean up deprecations from v2.x, and give users a path forward. I'm going to use this meta issue to list out the changes we're looking at making as we lead into release.

Requirements

These are the things that we must resolve before release:

• Upgrade history dependency to v3 (Add support for history@3.0.0 #3515)
  • If we go ahead with Use withFoo(history) enhancers history#322, we can probably drop the basename enhancer from the singleton histories, and let users use withBasename; given the removal of the automatic <base href> handling, adding the basename enhancer by default doesn't accomplish much
  • Should we force an initial replace to ensure that the initial location has a key when using browser history? cc @mjackson
• Factor out context subscriber code into separate package (Extract ContextUtils into react-context-subscriber #3484)

Wishlist

These are the things that I'd personally like to get to before release, but am willing to discard if they cause too much schedule slip:

• Pull out <LocationProvider> component to inject down location as a prop into a separate component that just handles routing state management
  • Would allow better Redux integration, since the matcher could then consume location from the store
  • Might not be possible? How do we interact with listenBefore?
• Move matching logic into route objects (Customizable URL matching rules #2286)
  • Instead of having a top-level matchRoutes handler, instead have the router ask each route for whether it matches, and the matched routes
  • This would allow creating e.g. <HapiRoute>, to allow users to use route handlers with their choice of route matching
  • We could get a proper routeParams too, as each route would give its matched params (Empty routeParams cause  #3549)
• Support returning promises from dynamic methods on routes (getComponent, getChildRoutes, &c.) (Feature request: Promise support in getComponent #3606)
  • This will allow better support for System.import
• Remove some edge case handling in default matching logic (with deprecations on v2.x)
  • Remove default support for nested absolute routes whose parents don't match (this can be handled in a custom-matching route) (Remove support for nested absolute routes #3172)
  • Change default pattern handling to path-to-regexp? This would make things easier to learn. We could warn on individual routes where the two matching algorithms give different results
• Split up client-side and server-side match helpers, since they don't do quite the same thing (Revisit server-side API and isolate into subdir #3290)
• Ensure that context subscriber handling works with context interceptors, as this will be needed for relative link support (but such support proper probably is too ambitious to squeeze into v3.0.0)

Well, please discuss.

The idea is to avoid any major breaking API changes – a working v2.x config should work with minor changes in v3.0.0. I'd like to take the opportunity to clean up cruft, but it's intentional that the wishlist is much longer than the list of requirements – I'm not going to be heartbroken if we can't get to some of these.

[taion]

Oops! Hit "submit" too quickly.

cc @reactjs/routing, @gaearon

The wishlist really is the wishlist. I'd like to get an rc.1 with the upgraded history dep this week if possible, and the rest is just "as we have time before we hit a reasonable release deadline".

[taion]

BTW, "support async route leave hooks" is I think an explicit non-feature here. Users should leverage the custom confirmation prompt support in history to accomplish showing custom dialogs there.

[timdorr]

Regarding the history v3 upgrade, how do we want to handle that? Should we support both v2 and v3 histories? The API change around location is rather significant, so I know it would break a number of tools (react-router-redux most notably, but the fix is really simple).

[taion]

I'm condensing and clearing out some earlier comments:

@dmitriid notes that the withRouter API doesn't match the API for route components in 2.x. This is resolved in 3.0.0-alpha.1, where withRouter also injects routes, params, and location. Thus, the injected props to a withRouter component mostly matches what's available to a route component, net of route, which we would need extra work to be able to inject. We will keep context.router as a supported API, subject to React not changing how context works under us, &c.

@umidbekkarimov mentions push handlers with special query support. We're currently not planning on implementing something along those lines, because the current push API is already quite good for merging and overriding queries:

router.push({ ...location, query: newQuery })
router.push({ ...location, query: { ...query, ...newQuery } })