Add support for history@3.0.0

[gajus]

Related to reactjs/react-router-redux#385.

[taion]

I don't think we can (easily) or should try to do this in a backward-compatible way BTW.

[julien-f]

Then maybe it should ship with react-router 3.0.0?

[gajus]

Delaying 3.0.0 release to include history@3 would make sense. Otherwise you'd have multiple major releases in relatively short time span.

On Jun 6, 2016, at 16:37, Julien Fontanet notifications@github.com wrote:

Then maybe it should ship with react-router 3.0.0?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[taion]

Ideally yeah. The user-facing API shouldn't change too much in any case.

[timdorr]

The biggest change is the listen behavior. Any ideas for adding a deprecation warning to that? I can only think of wrapping it to emulate the old behavior and adding a warning, but that will fire for everyone, regardless of if they've updated their code. Maybe an opt-in flag like we did for v2 histories?

[taion]

Not sure about that – in the v2 history change there was actually a discrete visible API change to the user whenever custom histories were involved (the mandatory user-called useRouterHistory).

For going to v3, the user-facing API shouldn't change in most cases – the user only needs to upgrade both libraries.

[deser]

Guys,
when it's planned to release react-router 3.0 ?
One more question:
As Breakage: history.listen no longer calls the callback synchronously once. maybe it would be possible to make setRouteLeaveHook asynchronous?

Thanks

[timdorr]

Apparently the next version isn't going to use history, so this is all moot. @mjackson says it should be out in a week or so.

Closing this in light of that news.

[taion]

Huh? Is that a good idea?

[timdorr]

I have no idea. No one was informed they were going off to do their own thing. That seems counter to the opening statements of #3289, but whatever...

[taion]

Hmm, I do think the API boundary between React Router and history has room for improvement, and the current situation is actually fairly confusing for users – see this issue and issues w/using e.g. use-named-routes with releases.

I do think it's useful to decouple history management from the router somewhat, but the current library pattern does have fixable flaws.

Looking forward to seeing it!

[timdorr]

Sure, I'm just whining about not being included in the cool kids club. 😄

I'm also for some further clarification because of confusion surrounding router state not being available in react-router-redux and that really being a history integration library (despite the name). It's also pretty confusing for users to have to learn and configure this entirely separate library if they want to do custom things (like named routes). It would be a bit like making your favorite dish with a different ingredient and having to learn how to farm in order to do it. It makes the API less fun to work with. So, hopefully this is going to be a more fun API 👍

[taion]

Just thinking about this a little, if I were doing a rewrite of history state management, I would:

1. Rewrite history to follow the new RN navigation paradigm, where the history is essentially just a reducer, written in such a way that it can plug into Redux (but also comes with a default store) – this makes Redux integration "just work" and better follows modern best practices for state management
2. Break up <Router /> into something like <LocationProvider><RouteMatcher /></LocationProvider>, and have the location injected down as a prop (so <LocationProvider> can be replaced with just the React Redux <Provider> if relevant), instead of having the same piece doing router state management also handle subscribing to the history.
3. Customizable route path matching engine (maybe route-by-route)

Hmm... if this rewrite gets stalled, I might actually try to move things in that direction.