react-router

is still quite a bit of churn going on with this library. Secondly I saw a post [4] that react-router is not the best solution if you use redux and that a more suitable library exists called react-little-router [5]. The argument is pretty convincing and it seems react-little-router is the way to go? But it is a lot less popular. I'm hoping some of those who are more experienced in React and Redux than me will weigh in with some thoughts and advice. Thanks in advance. [1] https://github.com/facebookincubator/create-react-app [2] http://redux.js.org/ [3] https://github.com/ReactTraining/react-router [4] https://formidable.com/blog/2016/07/11/let-the-url-do-the-talking-part-1-the-pain-… [5] https://github.com/FormidableLabs/redux-little-router

n to the history sub-project (which is a wrapper around location.hash, HTML5 pushState, and pure memory location state histories). history (which was a peerDep) was a big problem because we tried to stay hands off from that API as much as possible. This ended up putting a lot of mental load on the user, because they now had to be aware of and learn two libraries. So, we're now wrapping things up under a single API provided via `this.context.router` and provided pre-built history objects so you can choose what kind of history (hash or pushstate) you want with much less code and overhead. Another important thing in this upcoming version is backwards compatibility. We want to avoid the hassles you're having with things breaking all the time. If this version doesn't work with your code built for 1.0, then that's a bug and a blocker for release. We're following React's lead for post-1.0 versioning: https://gist.github.com/zpao/6e12ee0f46ce87af2287#versioning That is, we will release new APIs with each major version and deprecate but support any upcoming API removals. You'll have a chance to test against those removals by looking for dev-only warnings, but everything should work drop-in. As a bonus, we're also shipping a series of jscodeshift codemods to automatically upgrade your existing code to the newer APIs: https://github.com/rackt/rackt-codemod Check those out, because they're really cool and Jimmy Jia worked to make them a part of our upgrade path. Now, as for your mentioned issue, that was actually a change in a rc version. Yes, changing an API in a release candidate is bad. No way around it: that's our mistake. There was a good reason for this, as it caused bugs with React.Children.map: https://github.com/rackt/react-router/issues/1968 The 1.0 release process was super-rocky and we're looking to avoid that in the future. For 2.0, our API is stable and works to the best of our knowledge. No additions or removals will happen before the final version, so the rc badge is being properly used this time. We're also making sure our documentation for upgrades and general use are up-to-date and super-clear. The 2.0 API actually came about because Ryan Florence went to go make a screencast series and ran into many of the common problems with the 1.0 API. So, documentation drives our development pretty hard now. We still have a LOT to do, but we are working on it in earnest and my personal goal is to have some of the best documentation out there when all is said and done. If you have any other suggestions, criticisms, or questions about the APIs, please get in touch on Github via an issue or hop on the Reactiflux chat on Discord. We're all nice, reasonable guys who want to help and make this a great library for both power users and beginners alike. We need more feedback like this so we can make sure we're moving in the right direction. I promise we won't bite!