Rename lifecycle methods

[chiester]

Feature request: Can you consider renaming the byzantine lifecycle method names? I mean, come on, componentDidUpdate(), componentWillReceiveProps(), shouldComponentUpdate() ? React is declarative, huh? How about concise method names that "are easy to reason about" as React claims to be? How about rendered() ? Or updated().

Sometimes I think if the React team had invented REST, instead of GET and POST, we'd have clientWillRetrieveData and clientWillTransmitDataWithParameters.

A lifecycle implies the passage of time. How about method names that succinctly indicate where things are within that cycle? How about method names that are useful to developers building applications, not compound, portmanteau words that reflect internal engineering complexity.

[syranide]

Similar discussions has been had before. In my words, it's about being very explicit about the purpose and also that they are life-cycle methods (and thus special), not just regular methods.

Sometimes I think if the React team had invented REST, instead of GET and POST, we'd have clientWillRetrieveData and clientWillTransmitDataWithParameters.

Is that supposed to be a bad thing? Clarity always trumps being concise. The actual behavioral differences of GET and POST cannot be understood by just looking at the words without having experience with HTTP, whereas the hypothetical longer names actually could be understood by most people.

A lifecycle implies the passage of time. How about method names that succinctly indicate where things are within that cycle?

That's exactly what they do IMHO, componentWillMount, componentDidMount, etc? They are called before and after "mounting". Sure it's not obvious when componentWillReceiveProps is called, but is says what it does and you can guess pretty well when it will be called, it's hard to make it any clearer.

How about method names that are useful to developers building applications, not compound, portmanteau words that reflect internal engineering complexity.

That seems like hyperbole. How is updated() better than componentDidUpdate() other than being more concise? In my opinion it is less helpful because it doesn't hint at the fact that there is a before and after, they are not interchangeable, nor does it stand out among all the other "regular" functions in a large component. The other then being called willUpdate() or whatever would also probably bias a lot of people to use updated() because willUpdate() in context seems more complex and probably a special-case thing. updated() looks a lot like render() and easily seems more "official" then.

If you can give meaningful reasons/argue for what you think is wrong with the current names or come up with names that are objectively more descriptive/helpful then that would be helpful., But it's not obvious to me what's wrong with what we have other than you not liking it.

[tiye]

It's okay to me, but the only bad part is the word component is too long to write.

[gaearon]

It is intentionally long so that you use them sparingly, and so that it is easy to search for in giant codebases, safely replace automatically, etc.

[sundbry]

REST? You mean HTTP?

[gaearon]

I'll close this because it's an intentional design decision.
It is also documented as such and has been discussed before.

The lifecycles themselves will likely change to something more declarative after Fiber (#6170) is shipped. However whether something has a component prefix in it doesn't affect whether an API is declarative or not.

Thank you for your concerns!