I looked at Facebook's documentation at (React.Component) and it mentions how componentWillMount
is invoked on the client/server whereas componentDidMount
is invoked only on the client. What does componentWillMount
do to the server?

- 5,730
- 2
- 21
- 35

- 3,299
- 8
- 20
- 23
8 Answers
componentWillMount is essentially the constructor. You can set instance properties that don't affect render, pull data from a store synchronously and setState with it, and other simple side effect free code you need to run when setting up your component.
It's rarely needed, and not at all with ES6 classes.

- 84,529
- 20
- 165
- 173
-
1It is not the same as constructor. In strict mode in dev, for e.g., your constructor will be called twice (for two different instances) but only one will have componentWillMount called - https://stackoverflow.com/questions/61254372/my-react-component-is-rendering-twice-because-of-strict-mode – adarsh Oct 22 '20 at 12:37
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.

- 3,418
- 1
- 28
- 23
-
It's definitely not fine under all circumstances, depending on what's being on in `componentXxxMount`, e.g., Ajax in `willMount` can cause issues. – Dave Newton Aug 02 '16 at 11:17
-
2@DaveNewton I didn't say its fine on all circumstances. I just gave an example where there is a difference to prove that the answer "componentWillMount is essentially the constructor" is wrong. Thanks for clarifying it out – Liran Brimer Aug 03 '16 at 06:48
-
@LiranBrimer This answer is becoming inaccurate as componentWillMount is deprecated and will stop functioning in 0.16 and 0.17 respectively, particularly regarding the "However, dispatching from componentWillMount is just fine." statement – Brian Webster Aug 11 '19 at 17:42
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.

- 781
- 10
- 20

- 22,685
- 4
- 70
- 59
-
10`componentWillMount` will called on the server and the client. see: https://facebook.github.io/react/docs/component-specs.html#mounting-componentwillmount – David Jul 14 '16 at 06:28
-
1@DaveNewton how? It didn't say `componentWillMount` will not get called on client – Ayush Aug 06 '16 at 19:24
-
7@AyushShanker IMO it's important to provide non-misleading info. By not being explicit, there is room for misinterpretation: the docs are explicit. You are correct that it isn't explicitly contradictory as well. – Dave Newton Aug 06 '16 at 19:29
componentWillMount
is done before the INITIAL render
of a component, and is used to assess props and do any extra logic based upon them (usually to also update state), and as such can be performed on the server in order to get the first server side rendered markup.
componentDidMount
is performed AFTER the initial render
when the DOM has been updated (but crucially BEFORE this DOM update is painted to the browser, allowing you to do all kinds of advanced interactions with the DOM itself). This of course can only happen in the browser itself and so does not occur as part of SSR, as the server can only generate markup and not the DOM itself, this is done after it gets sent to the browser if using SSR
Advanced interactions with the DOM you say? Whaaaat??... Yep - at this point because the DOM has been updated (but the user has not seen the update in browser yet) it is possible to intercept actual painting to the screen by using window.requestAnimationFrame
and then do things like measure the actual DOM elements that will be output, to which you can perform further state changes, super useful for example animating to a height of an element that has unknown variable length contents (as you can now measure the contents and assign a height to the animation), or to avoid flash of content scenarios during some state change.
Be very careful though to guard state changes in any componentDid...
as otherwise can cause an infinite loop because a state change will also cause a re-render, and hence another componentDid...
and on and on and on

- 4,274
- 18
- 23
-
1I don't think adding `setState` in `componentDidMount` will cause an infinite loop. – Maddy Jan 17 '19 at 07:09
-
"*as otherwise can cause an infinite loop because a state change will also cause a re-render, and hence another componentDidMount. and on and on and on*", this is not true at all. State changes will cause re-render but it will not invoke `componentDidMount` again and again. componentDidMount is called only once when component gets mounted. – Gulam Hussain Nov 20 '19 at 06:34
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.

- 117
- 1
- 2
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.
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.

- 10,592
- 8
- 70
- 89
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);
}

- 264
- 2
- 10
ComponentDidMount()
Method only changes the current page in class components but ComponentWillMount()
changes all the pages which effected by setStates()

- 78
- 2
- 11