Given the fact you will remove (not recommend) to use this method anymore, but just componentDidMount to do a data fetch, for example, how will server rendering will work in the future (cause componentDidMount is not called on the server)?
componentWillMount was not useful for one-pass server rendering anyway because it is synchronous so you canāt wait for the data. So if you already have it synchronously, you might as well read it in the constructor.
If you did two rendering passes (which is bad for performance but somewhat works around the issue) then you can keep using UNSAFE_componentWillMount in the short term. Itās not safe for async rendering, but your code was already relying on a slow pattern (rendering twice) so itās better to be explicit about it.
In the longer term, the plan is to introduce first-class support for data fetching in React via an API weāre calling āsuspenseā. As mentioned in the blog post, we recently shared a sneak peek into the future of React, and the second part of the talk directly addresses this.
Hope it helps!
Thank you very much for your quick answer!
hi @gaearon , why componentWillMount is not safe for async rendering. Will the async rendering trigger componentWillMount twice?
@monkindey : yes, that's exactly why. React can pause and restart the process of rendering a component tree, in which case a component could _start_ to get mounted several times.
Thank @markerikson , it makes sense to me.
@gaearon Using a constructor you have more boilerplate than if you were to use componentWillMount. For example, this issue I made helps explain the issue: https://github.com/facebook/react/issues/10972
Not sure if there would be another lifecycle event that would act as a constructor because right now constructor initialization is like a one off when it could be more reusable.
If it's boilerplate you're specifically concerned about you can use the experimental (stage 3) class properties transform and write code like
class MyComponent extends React.Component {
state = {
color: this.props.initialColor
};
// ...
}
Thatās what we do at FB.
@gaearon Perfect! Thanks!
I actually don't understand why two phase rendering is bad, when you load data:
class Comp extends React.Component {
componentWillMount() {
const { loading, loadData } = this.props;
if (loading) {
loadData();
}
}
render() {
const { loading, data } = this.props;
return loading ? (
<div>please wait...</div>
) : (
<div>{data}</div>
);
}
}
Actually what is needed here is to render component twice, one time without data, one time with data.
Most helpful comment
componentWillMountwas not useful for one-pass server rendering anyway because it is synchronous so you canāt wait for the data. So if you already have it synchronously, you might as well read it in the constructor.If you did two rendering passes (which is bad for performance but somewhat works around the issue) then you can keep using
UNSAFE_componentWillMountin the short term. Itās not safe for async rendering, but your code was already relying on a slow pattern (rendering twice) so itās better to be explicit about it.In the longer term, the plan is to introduce first-class support for data fetching in React via an API weāre calling āsuspenseā. As mentioned in the blog post, we recently shared a sneak peek into the future of React, and the second part of the talk directly addresses this.
Hope it helps!