You Probably Don't Need Derived State

Let me address a few points.

>If you don't think users need this method, why put it out in the first place.

First of all, the article is not about the new method. It’s about patterns that has always caused bugs. This is repeated several times throughout the article, for example:

>All of the anti-patterns described in this post apply to both the older componentWillReceiveProps and the newer getDerivedStateFromProps.

We realized that people don’t often clearly understand better alternatives to these patterns (whether with old or new lifecycles) and write fragile and complicated code when there are simple solutions.

In this blog post, we tried to share some better solutions to those common patterns. I’m sorry if you didn’t find them useful, but I’m glad that it seems like you’ve never made those mistakes. Many people did, and found the post helpful.

Now, onto the topic of the lifecycle method changes.

I don't know if you’ve seen my talk at JSConf Iceland about async rendering but it’s really hard to explain the motivation if you haven’t. I know it’s a lot to ask but I would appreciate if you took 30 minutes of your time to watch it:

https://reactjs.org/blog/2018/03/01/sneak-peek-beyond-react-...

I’m sure you won't regret it, and I hope you will get as excited as I am about Time Slicing and Suspense. However, these features are not possible if we keep some of the less-clearly defined lifecycle methods like `componentWillUpdate` or `componentWillReceiveProps`.

Coincidentally, these legacy lifecycles tend to be the ones that people make most bugs or mistakes in. You might have already gotten used to them, but people have always been pretty confused about how they worked.

Most of the time those legacy lifecycles shouldn't have been used in the first place. For example, a lot of code that's placed in `componentWillUpdate` would work much better in `componentDidUpdate`.

>pushed by all the new core developers

For the rare cases where those legacy lifecycles were actually needed, we introduced safer alternatives, but as you rightly noted, you probably haven’t bumped into the use cases where you need them, so you don’t need to worry about them. We couldn’t just “leave them out” because we need to support all existing people’s use cases. Having a migration path is a core principle of React. We’re not “pushing” them.

Does that help at all? I know it’s frustrating when something familiar has been replaced with something less familiar. But again, most users won’t need them. And we can’t drop them because we care about supporting even rare use cases. We think the new features (Time Slicing and Suspense) will be worth the temporary confusion for our users, and I hope that after watching my talk you will agree.

I’m happy to talk to you more on Twitter or somewhere else. (http://mobile.twitter.com/dan_abramov/)

Cheers!