We need to be more effective at communicating our vision for the router. Hopefully we can do this constructively out in the open and get everyone's feedback. Also, I hope this document gives some guidance to people who've asked how they can help.
For now, here's a list of stuff that needs to happen, in no particular order:
<Link> active semantics (depends on #3158, see #3231 for discussion)As the discussion progresses, I'd like to expand this list, identify changes that we can make together and them into changesets with a release type (e.g. patch, minor, or major) so we can minimize upgrade pain.
Please keep comments short and to the point. Off-topic and excessively lengthy comments will be moderated.
Re: #3280, that was because of issues like #3279. #3285 has an additional fix for that case.
/foo/bar matches /foo////////bar//////. Among other problems, paths don't even have a "nearly canonical" form net of the trailing slash.useBasename strips the leading slash from location.pathname when the basename has a trailing slash. That's why @timdorr cherry-picked https://github.com/taion/rrtr/pull/8, which also adds a test case.<Link> would be breaking, and probably needs to come after removing support for nested routes with absolute paths. It's the correct resolution to https://github.com/reactjs/react-router/issues/3277, IMO.For the conditional stuff, what if the onEnter/onChange hooks had a 4th arg that was an error callback?
You can already call back with an error. The problem is that those errors can't be caught in a semantic way. Also, raising an error is not as rich as just falling through in routing. I really do think the API in #3098 is quite nice; it does exactly what's needed here.
I like that one too. Just brainstorming some other options in case there is something more palatable to those that don't like the extra prop.
I updated the OP to a checklist, and checked off the two things that we already resolved.
I'd like to merge @ryanflorence's applyMiddleware into core. No reason not to have it.
I'm making a tweak that @taion and I talked about last night before I make a pull request, it further simplifies creating middleware components.
We have two scroll management middlewares now: https://github.com/ryanflorence/react-router-restore-scroll, https://github.com/taion/react-router-scroll. Naturally, I like mine more, but we should probably have one with the union of the feature set :p
I'm going to fold this into an updated meta issue for the upcoming 3.x release, intended as a minor update to the 2.x API.
Tracking concrete goals and maybe-goals for v3.0.0 on https://github.com/reactjs/react-router/issues/3611.
Most helpful comment
I'd like to merge @ryanflorence's applyMiddleware into core. No reason not to have it.