React-router: Vision/Roadmap

Created on 13 Apr 2016  Â·  12Comments  Â·  Source: ReactTraining/react-router

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:

  • [x] Support trailing slashes. This was originally merged in #3158, reverted by @timdorr in #3280 (not sure why) and merged again in #3285. Needs a release.
  • [x] Simplify <Link> active semantics (depends on #3158, see #3231 for discussion)
  • [ ] Remove nested absolute paths (see #3172 for discussion, #3246 for PR). Per @taion's docs in #3178, this isn't actually a feature we need.
  • [ ] Scroll position management. See taion/scroll-behavior for a history enhancer approach. However, I agree with @taion when he says that it's something that needs to be integrated into the router core. I also agree with @ryanflorence when he says that it's very difficult to generalize scroll management, which is why we removed it in 1.0.

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.

Most helpful comment

I'd like to merge @ryanflorence's applyMiddleware into core. No reason not to have it.

All 12 comments

Re: #3280, that was because of issues like #3279. #3285 has an additional fix for that case.

3158 isn't supporting trailing slashes, it's dropping support for extra slashes. On 2.1.1, /foo/bar matches /foo////////bar//////. Among other problems, paths don't even have a "nearly canonical" form net of the trailing slash.

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

andrewpillar picture andrewpillar  Â·  3Comments

davetgreen picture davetgreen  Â·  3Comments

alexyaseen picture alexyaseen  Â·  3Comments

Radivarig picture Radivarig  Â·  3Comments

ArthurRougier picture ArthurRougier  Â·  3Comments