3 ms·
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 intera
by arrakeen 11y ago
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 11y agoYour 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 11y agoI'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 11y agoWe 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 11y agoIs there a doc on this? A simple example with pagination done client side or server side..that illustrates history.
- timdorr 11y agoWe normally hide this behind the `match` API: https://github.com/rackt/react-router/blob/master/docs/guides/advanced/ServerRendering.md 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.
- sandGorgon 11y agogotcha. 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.
- acjohnson55 11y agoI'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.