For any client application there are two scenarios, when you integrate api.
1 | Based On User Interactions : To handle user interactions such as clicks, scrolls etc. These are the events and they have their own Event Handlers dedicated to each user behaviour. So you can place the api calls in that particular handler.
2 | When component Loads : When component initially loads, it may be required to load some initial data from server. For example, in your apllication which displays restaurants in your area, you need to call list of restaurants to display on landing page.
And here comes the confusing part. Where to call the api?
wait… what.? what is confusing in it. Just make a call in lifecycle
componentWillMount, it is called just before the render is invoked.
Yes, You may think it is the best place to make api calls. This misconception is always been there in the react community. Let’s understand this with an example. There are 3 reasons, to not use this lifecycle -
➀ The common misconception is that fetching data in
componentWillMount will avoid first empty render. But is was never true in react, because react has always executed
render immediatly after
componentWillMount. If the data is not available by the time of first render, it will always show loading state regardless of where you put the fetch api.
componentWillMount()is invoked just before mounting occurs ( called before render ), so calling
setState()synchronously in this lifecycle will not trigger extra rendering.
➁ This lifecycle is also called at the server side (if you are using SSR). In this case the external data won’t be used. So the api will be called twice unnecessarily.
componentWillMount is considered legacy, alias
UNSAFE_componentWillMount is introduced in React v16.3 and will be depricated after React v17. After React v17 only the alias will work fine.
Please refer to following link for smooth migration to newer version of react.
Migration Path for unsafe lifecycles in React.
There was a discussion in react community to depricate some legacy component lifecycles that tend to encourage unsafe…
I hope you are clear with this lifecycle. Lets consider another good candidate for making api call.
When loading initial data of app, many developers think that they can use
constructor as we have been tought that constructor is used for initialization.
A typical react constructor is used for two purpose -
➀ Initializing local state by assigning an object to
➁ Binding event handler methods to an instance.
Fetching data in constructor is considered to be a side effect and it is recommended to avoid that. As you all know we cannot call
setState() in the constructor.
If a constructor has side effects like a Redux / Flux Store dispatch, then other components may get their
setState() called. They will log a warning that
setState() cannot be called from
This warning is misleading because this is not what happened. It protects against
setState() calls from
render() but what really happens is one component causing a side effect in its constructor, leading to other component getting its
You can refer to following disussion for this-
Triggering async data request in ES6 "constructor()" or "componentWillMount()" or…
(I'm fairly new to React and Redux, and so I'm still trying to figure out the best coding patterns and practices, so…
React docs recommended that it is the best candidate for fetching data. Because -
➀ This lifecycle is called only at the client.
➁ We have seen in the example above that we cannot avoid first empty render. So we can use
componentDidMount instead of
componentWillMount and without any impact in majority of cases write above example as
componentDidMount() will trigger an extra rendering, but it will happen before the browser updates the screen. This guarantees that even though the
render() will be called twice in this case, the user won’t see the intermediate state.
componentDidMount is the best place to make network request to fetch data.
At this point you might be clear with the concept, I hope so :). If you think i missed anything or you would like to suggest something, please mention in the comments. And if you like the article you can applaud as well. :)