I looked at Facebook\'s documentation at (React.Component) and it mentions how componentWillMount
is invoked on the client/server whereas componentDidMou
To add to what FakeRainBrigand said, componentWillMount
gets called when rendering React on the server and on the client, but componentDidMount
is only called on the client.
As per the documentation ( https://facebook.github.io/react/docs/react-component.html )
Methods prefixed with will are called right before something happens and
Methods prefixed with did are called right after something happens.
Use-case for the componentWillMount()
For example, if you want to keep the date of when the component was created in your component state, you could set this up in this method. Please keep in mind that setting state in this method won’t re-render DOM. This is important to keep in mind, because in most cases whenever we change the component’s state, a re-render is triggered.
componentWillMount() {
this.setState({ todayDate: new Date(Date.now())});
}
Use-case for the componentDidMount()
For example, if you were building a news app that fetches data on the current news and displays it to the user and you may want this data to be updated every hour without the user having to refresh the page.
componentDidMount() {
this.interval = setInterval(this.fetchNews, 3600000);
}
ComponentDidMount()
Method only changes the current page in class components but ComponentWillMount()
changes all the pages which effected by setStates()
the constructor
method is not the same as componentWillMount
.
According to the author of Redux, it is risky to dispatch actions from the constructor because it may result in mutating the state while rendering.
However, dispatching from componentWillMount
is just fine.
from github issue:
This happens when dispatch() inside one component's constructor causes a setState() inside another component. React keeps track of the “current owner” for such warnings—and it thinks we're calling setState() inside the constructor when technically constructor causes a setState() inside some other part of the application. I don't think we should handle this—it's just React trying its best do its job. The solution is, as you correctly noted, to dispatch() inside componentWillMount() instead.
componentWillMount https://daveceddia.com/where-fetch-data-componentwillmount-vs-componentdidmount/
There’s a “gotcha,” though: An asynchronous call to fetch data will not return before the render happens. This means the component will render with empty data at least once.
There is no way to “pause” rendering to wait for data to arrive. You cannot return a promise from componentWillMount or wrangle in a setTimeout somehow.
https://developmentarc.gitbooks.io/react-indepth/content/life_cycle/birth/premounting_with_componentwillmount.html
our Component will not have access to the Native UI (DOM, etc.). We also will not have access to the children refs, because they are not created yet. The componentWillMount() is a chance for us to handle configuration, update our state, and in general prepare for the first render. This means we can start performing calculations or processes based on the prop values.