6 ms·

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 freque

by n0us 11y ago

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 11y ago
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 11y ago
  Yeah same here. Using it in production has cost some time upgrading. Not looking forward to another upgrade just a few months later.
  - jrcii 11y ago
    Unfortunately this captures the problems I face developing with JavaScript (frameworks and libraries du jour) in general.
  - dham 11y ago
    Same here. Every time I download it, the API is totally different.
  - cnp 11y ago
    If they had a proper documentation website perhaps the situation would be better.
- rileyt 11y ago
  I couldn't agree more. I have used react-router for 3 side projects now, each time with a new interface and no real benefit over the last version, not to mention more outdated docs and advice.
dustingetz 11y ago
You are free to evaluate the stability of any open source projects you would like to use, and if they provide insufficient value, you may get involved, or donate, or use any of the competitors like Backbone.Router or write your own, or otherwise add value to the ecosystem yourself. Fast paced innovation is good. If you don't like life on the edge, it's not like these problems were unsolved last year. Use those solutions.
fvargas 11y ago
FWIW, `this.props.children` is an opaque data structure and should be treated as one. https://facebook.github.io/react/docs/top-level-api.html#react.children https://facebook.github.io/react/docs/top-level-api.html#rea...
taion 11y ago
Our top priority after we get 2.0 solidly released is to revamp the documentation and provide a better tutorial. The work that Dan Abramov has done with introducing Redux is a positive example to all of us. As for the change to the case with using multiple named child components - we made that change because React upstream made it no longer valid to pass objects into this.props.children. It wasn't that we decided one way or the other that it was nicer to spread named children into top-level props; the old way that we did it (which for this case was arguably cleaner) was literally no longer supported by React, so we had no choice.
- spicyj 11y ago
  That doesn't sound right. You can pass whatever you want as props to a composite component; you just can't use objects as a list of children in a DOM component, but that's not what you were doing before. When Ryan Florence filed an issue with seemingly your same misconception, we told him the same and never heard back: https://github.com/facebook/react/issues/5371 https://github.com/facebook/react/issues/5371 What am I missing?
timdorr 11y ago
Hey, I'm on the rackt team and work on both react-router and redux. I joined on around the time of the 1.0 rc's. I can't really speak to the pre-0.13 days, but I've been involved in this most recent rewrite pretty heavily. A lot of the motivations from 0.13 to 1.0 were around the APIs very liberally mixing React conventions with plain Javascript conventions, with a dash of callback hell thrown in for good measure. In addition, getting access to a lot of the internal APIs for integrations with things like redux and relay was very difficult. So, there was a very large rewrite to better modularize the code and improve the semantics of the API. I think they got pretty close to a good goal, but obviously there was room for improvement. 2.0's motivations have been around further simplifying a lot of the API surface area, particularly in relation 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 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 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 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!
bpicolo 11y ago
This has been an issue for me with the entire React ecosystem. Trying to get react hot loading working between all the expected latest packages last week was insanely hard.

by n0us 11y ago

cortesi 11y ago

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 11y ago
Yeah same here. Using it in production has cost some time upgrading. Not looking forward to another upgrade just a few months later.
- jrcii 11y ago
  Unfortunately this captures the problems I face developing with JavaScript (frameworks and libraries du jour) in general.
- dham 11y ago
  Same here. Every time I download it, the API is totally different.
- cnp 11y ago
  If they had a proper documentation website perhaps the situation would be better.
rileyt 11y ago
I couldn't agree more. I have used react-router for 3 side projects now, each time with a new interface and no real benefit over the last version, not to mention more outdated docs and advice.

dustingetz 11y ago

You are free to evaluate the stability of any open source projects you would like to use, and if they provide insufficient value, you may get involved, or donate, or use any of the competitors like Backbone.Router or write your own, or otherwise add value to the ecosystem yourself. Fast paced innovation is good. If you don't like life on the edge, it's not like these problems were unsolved last year. Use those solutions.

fvargas 11y ago

FWIW, `this.props.children` is an opaque data structure and should be treated as one. https://facebook.github.io/react/docs/top-level-api.html#react.children https://facebook.github.io/react/docs/top-level-api.html#rea...

taion 11y ago

Our top priority after we get 2.0 solidly released is to revamp the documentation and provide a better tutorial. The work that Dan Abramov has done with introducing Redux is a positive example to all of us. As for the change to the case with using multiple named child components - we made that change because React upstream made it no longer valid to pass objects into this.props.children. It wasn't that we decided one way or the other that it was nicer to spread named children into top-level props; the old way that we did it (which for this case was arguably cleaner) was literally no longer supported by React, so we had no choice.

spicyj 11y ago
That doesn't sound right. You can pass whatever you want as props to a composite component; you just can't use objects as a list of children in a DOM component, but that's not what you were doing before. When Ryan Florence filed an issue with seemingly your same misconception, we told him the same and never heard back: https://github.com/facebook/react/issues/5371 https://github.com/facebook/react/issues/5371 What am I missing?

timdorr 11y ago

Hey, I'm on the rackt team and work on both react-router and redux. I joined on around the time of the 1.0 rc's. I can't really speak to the pre-0.13 days, but I've been involved in this most recent rewrite pretty heavily. A lot of the motivations from 0.13 to 1.0 were around the APIs very liberally mixing React conventions with plain Javascript conventions, with a dash of callback hell thrown in for good measure. In addition, getting access to a lot of the internal APIs for integrations with things like redux and relay was very difficult. So, there was a very large rewrite to better modularize the code and improve the semantics of the API. I think they got pretty close to a good goal, but obviously there was room for improvement. 2.0's motivations have been around further simplifying a lot of the API surface area, particularly in relation 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 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 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 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!

bpicolo 11y ago

This has been an issue for me with the entire React ecosystem. Trying to get react hot loading working between all the expected latest packages last week was insanely hard.