Add warning for componentDidReceiveProps()

[iamtommcc]

As per Dan's suggestion on Twitter, this is a tiny little PR that adds componentDidReceiveProps to the list of invalid lifecycle methods to throw warnings for.

[acdlite]

Could also have meant componentWillReceiveProps()? Let's include both

[gaearon]

I think in most cases people would mean componentWillReceiveProps.

Maybe we should say

If you meant to update the state in response to changing props, use componentWillReceiveProps(). If you meant to perform manual DOM manipulations or fetch data, use componentDidUpdate().

[acdlite]

I like that, though will also be seen for non-DOM users.

[gaearon]

Maybe

If you meant to update the state in response to changing props, use componentWillReceiveProps(). If you meant to fetch data or run some code after React has updated the UI, use componentDidUpdate().

[acdlite]

"some code" -> "side-effects or mutations"

?

[gaearon]

👍

outdated

[gaearon]

LGTM. Thanks!

[trueadm]

Isn't this a major change? At a previous company I worked at, we added a componentDidReceiveProps method to a HOC that didn't fire it if setState() was used to update itself. I believe this would now break that user-land method?

A better idea might be to reserve method names (DEV only) like these in a future version. This will lock them down so no-one can use them and in turn we can provide better errors in general?

[gaearon]

Not break, but it will add a warning. We routinely add warnings in minor versions and if that breaks your build, we recommend locking down the dependencies.

In this case my feeling is that it's more likely this will be beneficial (and possibly uncover unintentional mistakes) to most users. People who overloaded it with a special meaning can always rename their version with a global find-replace.

I'd say in general it is a bad idea to name non-React things with names like componentDid*. Since people reading that code will certainly think it's part of React, won't be able to find it in the docs, and potentially can even use it outside of the context where it works (e.g. in that HOC).

[swyxio]

I'd say in general it is a bad idea to name non-React things with names like componentDid*

naming things is hard, might want to formalize this somewhere in the docs? any other naming issues that people usually run into? i'll move this over to the docs repo but just getting ideas

[gaearon]

To be honest I don't think this is common enough to highlight it in docs. If anything, it's better not to give people the idea to create such methods by mentioning it :-)