Why do the React docs recommend doing AJAX in componentDidMount, not componentWillMount?

Question

I understand why componentDidMount is appropriate for anything that requires DOM access, but an AJAX request doesn’t necessarily or usually need this.

What gives?

• ZekeDroid: @FurkanO I think he meant access to DOM elements rendered by the component. And he is entirely right because if you were to attempt to access said elements in componentWillMount it would fail given that the component...didn't mount.
• FurkanO: @AlanH. Deleted my question, of course you have access to dom on componentDidMount. This is a rule, nothing to explain about it. Thanks.
• Faris Rayhan: In my opinion was why we call Ajax function after componentDidMount is we have to make sure first that the Element is rendering smoothly at the beginning. After that we can do ajax call. If we call ajax first and something error happens it will cause problem on rendering

Answer 1

componentDidMount is for side effects. Adding event listeners, AJAX, mutating the DOM, etc.

componentWillMount is rarely useful; especially if you care about server side rendering (adding event listeners causes errors and leaks, and lots of other stuff that can go wrong).

There is talk about removing componentWillMount from class components since it serves the same purpose as the constructor. It will remain on createClass components.

• Alan H.: Adding event listeners causes errors and leaks all the time on the server, or just in componentWillMount? I don’t really see the distinction.
• Mike Driver: @Alan - If you are using React on both clientside and serverside you'll find that anything inside componentWillMount will be executed on a serverside render. Wheras if you were using componentDidMount then that would only be executed on clientside. As a result putting things in componentWillMount that perform external interactions or bind to events etc, is not a great idea. If you have no plans to render your components on serverside, it's still not a good idea just for potential code portability. This is all outside the main reason it's bad which is explained in @daniula 's answer.
• Brigand: componentWillMount is run on the server, but componentWillUnmount (where you remove listeners) isn't. This would cause you to add listeners and never clean them up.
• cchamberlain: People on the React core team are considering removing componentWillMount from future versions.
• Brigand: @AnkitSinghaniya it'd break server rendering and shallow unit tests.

Answer 2

I had the same issue at the beginning, too. I decided to give a try making requests in componentWillMount but it end up in various small issues.

I was triggering rendering when ajax call finishes with new data. At some point rendering of component took more time than getting response from server and at this point ajax callback was triggering render on unmounted component. This is kind of edge case but there is probably more, so it's safer to stick to componentDidMount.

• Alan H.: Okay, thanks. Thought it might be something like that, but you’re right, it is surprising that the ajax request could finish before the render does.
• Leon Grapenthin: @daniula Are you sure? How can the AJAX request finish before render?
• daniula: This is browser asynchronous world. You should never assume that one function will always be faster then the rest. As I've mentioned it's edge case and probably means that you should optimize your rendering process but using proper lifecycle method will make your life much easier at this point.
• daniula: @SooChengKoh ES6 class constructor is equivalent of componentWillMount, so you should still keep using componentDidMount for your ajax calls.
• cchamberlain: @SooChengKoh - Definitely should not do anything in the constructor that will lead to state that must be set, that will lead to race conditions on client and server. You should never call setState in a component constructor and you have no way of determining when the AJAX call will complete. twitter.com/dan_abramov/status/576453138598723585

Answer 3

According to documentation setting the state in componentWillMount will no trigger a re-rendering. If the AJAX call is not blocking and you return a Promise that update the component's state on success, there are chances that the response arrives once the component has been rendered. As componentWillMount doesn't trigger a re-render you won't have the behaviour you expected which is the component being rendered with the requested data.

If you use any of the flux libraries and the data requested end up in the store the component is connected to (or inherit from a connected component) this won't be an issue as the reception of that data will, most likely, change props eventually.

• webdif: componentWillMount does not trigger a re-render just because a new state is defined before the first render. But if setState is called in a AJAX callback, it will be most definitely called after the first render, and it will trigger a re-render.