Comment by arrakeen | Hacker News Reader

Comment by arrakeen | Hacker News Reader

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

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.

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.

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.

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

We normally hide this behind the `match` API: https://github.com/rackt/react-router/blob/master/docs/guide...

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.

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.

I'm working on a universal app right now, and I've found a lot of success factoring aspects like middleware setup and router setup, so that they can differ between client and server sides. On the server side, no actions are ever dispatched, so no router methods ever get called. The only thing I use the Router for is matching the route to know what to pre-fetch before rendering.

Reply on news.ycombinator.com