Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Deprecate React.addons.update #2909
Sorry about the dupe. Maybe as the first subtask here, we can de-emphasize this addon in the documentation?
My thinking is to rewrite https://facebook.github.io/react/docs/update.html to first suggest using array spread/object spread syntax (
Second, mention immutable-js for more advanced scenarios where you need to make deeply-nested updates. In my experience well-written React code rarely needs to update state nested more than one level deep, so I disagree with the current doc's implication that such deep nesting is common or natural (what do you think?).
Then, only lastly, document
Immutable.js and the update addon are different. With the update addon you keep plain js objects, while immutable.js has custom wrapper objects. The update addon is useful for components where you don't want to make assumptions, while immutable.js is good for situations where you can make assumptions. They're both valid tools to use.
As I mentioned in #5780 there's some risk involved in that that makes it worth considering whether you want to encourage people to do it, and tip them off about the risk.
FWIW it's probably more common with something like Redux, which mentions using this helper. (Obviously what other libraries are doing is beside the point of what you want to ship / document here, and the helper will be available as an independent package anyway.)
This might be helpful if we decide to rewrite the doc to use the spread operator: http://redux.js.org/docs/recipes/UsingObjectSpreadOperator.html
referenced this issue
Apr 15, 2016
referenced this issue
Aug 15, 2016
Food for thought.
If you create a react-community organization, you could extract addons and the like into repos there, and stipulate that react-community projects are not actively developed or used by Facebook, but PRs and bugfixes from the community are still welcome. Elm uses this method to extend the functionality of its core libraries when it's not certain said functionality belongs in the core.
If you do fork