
React Router 2.0.0 - tilt
https://github.com/rackt/react-router/blob/master/upgrade-guides/v2.0.0.md
======
n0us
React Router works well enough but I've had a lot of problems using it. One
issue in particular I've had with this project is that they change the API so
frequently that it's often difficult or nigh impossible to find documentation
on issues, how to do X, or access property Y. There are the official docs, but
sections have been scant or incomplete, and in some cases wrong. Crucial
information might be omitted or only found in another location. Reading other
people's projects or old issues is a pain because there is example of using
API "X" but now it is named "Y" and does exactly the same thing so you have to
go look up the release notes to even find out if the issue is relevant to you.

My project broke the other day because when you provide multiple child
components it used to create an object that was
"this.props.children.component1" but now it just does "this.props.component1".
But when you only pass one component it is still named "this.props.children"
in spite of there only being one component. I was unable to find any
convincing reasoning for making this change. Does exactly the same thing.
Makes the interface less sensible in my opinion. Caused me to do unnecessary
work to achieve exactly the same result.

I get that changes are necessary when they change functionality but a lot of
times it seems things have just changed with no reasoning other than just
changing for the sake of changing. Maybe I'm being unreasonable and overly
picky but I wish they would just keep the API stable and make the changes
behind the scenes.

~~~
cortesi
This matches my experience with react-router. I use it in a few side projects,
and I have the feeling that there's been a lot of "design-thrash" \- every new
release seems to bring a new interface and new ways of doing things, without
much real benefit.

~~~
49531
Yeah same here. Using it in production has cost some time upgrading. Not
looking forward to another upgrade just a few months later.

~~~
jrcii
Unfortunately this captures the problems I face developing with JavaScript
(frameworks and libraries du jour) in general.

------
arrakeen
after banging my head against react-router for a side-project the past couple
of weeks, reading that one of their motivations for 2.0 was to clean up the
interaction between history and router was a sigh of relief. looking at the
docs, however, made it clear that they are doubling down on their strange and
confusing history API:

    
    
      import { useRouterHistory, hashHistory } from 'react-router'
      // useRouterHistory creates a composable higher-order function
      const appHistory = useRouterHistory(hashHistory)({ queryKey: false })
      <Router history={appHistory}/>
    

if i wanted to change the scroll behavior of router, then i'd have to do
something like this:

    
    
      import useScroll from 'scroll-behavior/lib/useStandardScroll'
      const appHistory = useScroll(useRouterHistory(hashHistory))({ queryKey: false })
    

how does this make using router/history any clearer?

i LIKE react-router, i think it's pretty damn good, but I just don't
understand the rationale for their API choices. combine that with the velocity
at which they're changing the APIs, it makes me wish that they'd just take
their time with the design

~~~
taion
Your code example is actually wrong. The intended API use looks like:

    
    
      import { Router, browserHistory } from 'react-router';
    
      const router = <Router history={browserHistory} />;
    

One perk is that you can then navigate using the singleton if you want, e.g.
with

    
    
      browserHistory.push('/foo');
    

The scroll behavior stuff is definitely messy; I haven't had time to clean it
up. The nice thing about OSS, though, is that the rest of you are all free to
contribute changes.

~~~
roblabla
I'm personally averse to the whole singleton thing. What about server side
rendering? You don't want the history to be shared across requests.

Most projects already have their own ways to pass dependencies (through DI or
whatnot), and I can't help but feel like providing those singletons is going
to end up messy.

~~~
timdorr
We export createMemoryHistory instead of a singleton for the server. If you
don't like the singletons on the browser side, you can use the useRouter
enhancer to pop in any history creation function you'd like.

~~~
sandGorgon
Is there a doc on this? A simple example with pagination done client side or
server side..that illustrates history.

~~~
timdorr
We normally hide this behind the `match` API: [https://github.com/rackt/react-
router/blob/master/docs/guide...](https://github.com/rackt/react-
router/blob/master/docs/guides/advanced/ServerRendering.md)

Of course, that API is quite opaque and doesn't give you a history object you
work with. It's really just a boilerplate reducer or macro for SSR. You can
copy out what's going on inside of the function, but that's pretty crappy for
you to have to manage.

I think, in addition to the docs sucking, we need to come up with a better API
for SSR. If you're using redux-simple-router or other integrations that rely
on history, it's entirely unusable. We need to fix this.

~~~
sandGorgon
gotcha. do you have an example for the client side history management with ES6
? Its been a challenge to figure out the right documentation for ES6 -
especially the proptypes declaration.

I dont think you need to do a lot of explanatory docs - if you have canonical
examples, that would be more than enough.

------
biscarch
React Router has been iterating towards better APIs for advanced use cases
(server-side rendering, code splitting, relay (and other lib) integration,
etc). Having used it in projects spanning the above use cases, the evolution
of the API has been welcome change.

I'm also happy to see codemods and other AST manipulations (such as babel
plugins) gaining popularity. Similar to eslint's --fix, codemods are making
repetitive changes easier across large codebases.

------
dominotw
I skeptical of benefits of declarative routing. My project got much simpler
after I got rid of react-router.

~~~
Bahamut
I'm skeptical of this as well, and while I had no problems with react-router
on a side project, I have misgivings with the router being coupled to JSX -
IMO, this is an unnecessary coupling of what should be service logic to
components.

~~~
acjohnson55
It's not necessary at all to use JSX to describe your route configuration.
Just use POJOs instead.

------
druska
You made it seem like this is released. Right now the official version is
v2.0.0-rc4.

------
tbrock
I think it may be time for the community or Facebook to write something that
replaces react-router.

It has been extremely difficult to build something on top of it and keep
current. Pre-1.0 I can understand the API thrash but 1.0->2.0 in a couple
months?

Facebook should carry the torch here and write a standard router. This is a
core component critical to the success of React for any applications more
complicated than a dashboard.

~~~
insin
I don't undestand this expectation, there's nothing magic about 1.0.

They thought they had the API figured out for various use cases beyond the
core routing functionality, but it turns out they didn't.

In addition, 2.0 is supposed to be backwards-compatible for end users _and_
they're providing codemods to help you update when it's convenient to do so.

------
linkmotif
There are aspects of React Router that are annoying, but I am glad not to be
writing code for matching routes. Works for me.

Also a fan of [https://github.com/relay-tools/react-router-
relay](https://github.com/relay-tools/react-router-relay), because Relay is
great.

~~~
taion
What do you find annoying about React Router?

If anything, working on react-router-relay has only made me appreciate React
Router's design more.

A lot of the changes in 2.x are specifically from lessons we've learned in
building react-router-relay and other integrations, but they're closer to
refactorings and code reorganization than to wholesale rewrites.

~~~
linkmotif
Generally what many others have said: that the API has changed a lot.

Specifically I didn't like it when named routes were removed.

But hey—it's open source. Sometimes I get worked up about this or that, but
then I remember that all of this I'm getting for free and I must be grateful.

------
shabbaa
I'm glad to see this thread and some debate about react router and it's
features and ways it could be better. Too often any react critisism is
attacked almost fanatically.

------
cheapsteak
1.0 was released in _November_, it's not even been two months. This is quite
discouraging

~~~
timdorr
Node has been upgrading quickly too. Counting io.js:

    
    
       4.0.0 -> 5.0.0 - 7 weeks   
       3.0.0 -> 4.0.0 - 5 weeks   
       2.0.0 -> 3.0.0 - 3 months
    

Semver will do that :)

~~~
cheapsteak
Apologies, I missed perhaps the most important sentence

> It's hard to imagine the top-level API changing much after this.

Very glad to hear that and hope it will indeed become stable after this

