Add support for [email protected]

[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 [email protected] 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.

[timdorr]

Number 2 and 3 are pretty close to what Ryan and Michael are working on (Ryan showed me what they have so far on Friday). I don't think anything is going to stall, since they're pretty excited about it (I am too!). They'll loop us in soon.

[taion]

Sure – I'd say that once you factor out a location provider component, then that component really should use history or a similar abstraction if practical.

[timdorr]

Oh yeah, it still does use history. I misread some things.

[taion]

@gaearon recommended that we cut a v3 release with a relative small changeset ahead of the pending rewrite to give users a path forward, with improvements from v2. I'm re-opening this issue and adding it to the v3 milestone.

This is blocked on remix-run/history#316, and also on the question of how to handle getting the initial location – i.e. should we do a history.replace(currentLocation) in the router to ensure that the initial location always has a key on it (when e.g. using browser history)?

cc @mjackson

[deser]

So let me repeat my question:

As Breakage: history.listen no longer calls the callback synchronously once. maybe it would be possible to make setRouteLeaveHook asynchronous?

[timdorr]

No, the listen change has no bearing on setRouteLeaveHook. It simply changes the first call behavior.

[deser]

:(

[taion]

There is no plan right now to make leave hooks async. If you want more complex confirmation behavior, take a look at extending the behavior of history's navigation confirmation hooks to better work with custom confirmation dialogs.

[taion]

Folded into #3611.

[taion]

#3647