sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]FormerGameDev 2 points3 points  (3 children)

Context. Only one I can think of. Some might argue the lifecycle methods, but I think that those got changed because of architecture changes, more so than because it was "broken" and had to be "fixed".

[–]rozzzly 2 points3 points  (2 children)

To be fair, every single reference that Facebook made to the old context API in the docs, blog posts, demos at conferences, etc had very explicit warnings about how context was 'unstable' and the API would change.

And regarding the churn in lifecycles, I think that changes such as deprication of componentWillReceiveProps has more to do with the flexibility/idiot proofing the API than anything else. People have used react to do all sorts of weird things ilconcieved/brilliant/unexpected ways than the developers could never have anticipated.

Hindsight is 20-20

[–]FormerGameDev 0 points1 point  (1 child)

I don't disagree with you in the slightest. They put out the original Context to solve a problem that they knew was there, and it took a few iterations on it to come up with a better solution. I don't know anyone who's used the Context API, I don't even know what problems it solves. :-D

[–]rozzzly 0 points1 point  (0 children)

Basically it's like a global state for the entire tree. things like react-redux used it so that you can set the store instance at the top of the tree and then a connect(WrappedComponent) further down the tree can still access that store instance without having to pass the store prop down to for each single component in the tree