Is using async componentDidMount() good?

Question

Is using componentDidMount() as an async function good practice in React Native or should I avoid it?

I need to get some info from AsyncStorage when the component mounts, but the only way I know to make that possible is to make the componentDidMount() function async.

async componentDidMount() {
    let auth = await this.getAuth();
    if (auth) 
        this.checkAuth(auth);
}

Is there any problem with that and are there any other solutions to this problem?

Answer 1

Let's start by pointing out the differences and determining how it could cause troubles.

Here is the code of async and "sync" componentDidMount() life-cycle method:

// This is typescript code
componentDidMount(): void { /* do something */ }

async componentDidMount(): Promise<void> {
    /* do something */
    /* You can use "await" here */
}

By looking at the code, I can point out the following differences:

1. The async keywords: In typescript, this is merely a code marker. It does 2 things:
   • Force the return type to be Promise<void> instead of void. If you explicitly specify the return type to be non-promise (ex: void), typescript will spit an error at you.
   • Allow you to use await keywords inside the method.
2. The return type is changed from void to Promise<void>
   • It means you can now do this:
     async someMethod(): Promise<void> { await componentDidMount(); }

3. You can now use await keyword inside the method and temporarily pause its execution. Like this:

   async componentDidMount(): Promise<void> {
       const users = await axios.get<string>("http://localhost:9001/users");
       const questions = await axios.get<string>("http://localhost:9001/questions");
   
       // Sleep for 10 seconds
       await new Promise(resolve => { setTimeout(resolve, 10000); });
   
       // This line of code will be executed after 10+ seconds
       this.setState({users, questions});
       return Promise.resolve();
   }
   

Now, how could they cause troubles?

1. The async keyword is absolutely harmless.

2. I cannot imagine any situation in which you need to make a call to the componentDidMount() method so the return type Promise<void> is harmless too.

   Calling to a method having return type of Promise<void> without await keyword will make no difference from calling one having return type of void.

3. Since there is no life-cycle methods after componentDidMount() delaying its execution seems pretty safe. But there is a gotcha.

   Let's say, the above this.setState({users, questions}); would be executed after 10 seconds. In the middle of the delaying time, another ...

   this.setState({users: newerUsers, questions: newerQuestions});

   ... were successfully executed and the DOM were updated. The result were visible to users. The clock continued ticking and 10 seconds elapsed. The delayed this.setState(...) would then execute and the DOM would be updated again, that time with old users and old questions. The result would also be visible to users.

=> It is pretty safe (I'm not sure about 100%) to use async with componentDidMount() method. I'm a big fan of it and so far I haven't encountered any issues which give me too much headache.

Answer 2

Update April 2020: The issue seems to be fixed in latest React 16.13.1, see this sandbox example. Thanks to @abernier for pointing this out.

---

I have made some research, and I have found one important difference: React does not process errors from async lifecycle methods.

So, if you write something like this:

componentDidMount()
{
    throw new Error('I crashed!');
}

then your error will be caught by the error boundary, and you can process it and display a graceful message.

If we change the code like this:

async componentDidMount()
{
    throw new Error('I crashed!');
}

which is equivalent to this:

componentDidMount()
{
    return Promise.reject(new Error('I crashed!'));
}

then your error will be silently swallowed. Shame on you, React...

So, how do we process errors than? The only way seems to be explicit catch like this:

async componentDidMount()
{
    try
    {
         await myAsyncFunction();
    }
    catch(error)
    {
        //...
    }
}

or like this:

componentDidMount()
{
    myAsyncFunction()
    .catch(()=>
    {
        //...
    });
}

If we still want our error to reach the error boundary, I can think about the following trick:

1. Catch the error, make the error handler change the component state
2. If the state indicates an error, throw it from the render method

Example:

class BuggyComponent extends React.Component {
  constructor(props) {
    super(props);
    this.state = { error: null };
  }
  
  buggyAsyncfunction() { return Promise.reject(new Error('I crashed async!'));}
  
  async componentDidMount() {
    try
    {
      await this.buggyAsyncfunction();
    }
    catch(error)
    {
        this.setState({error: error});
    }
  }
  
  render() {
    if(this.state.error)
        throw this.state.error;
        
    return <h1>I am OK</h1>;
  }
}

Answer 3

Your code is fine and very readable to me. See this Dale Jefferson's article where he shows an async componentDidMount example and looks really good as well.

But some people would say that a person reading the code may assume that React does something with the returned promise.

So the interpretation of this code and if it is a good practice or not is very personal.

If you want another solution, you could use promises. For example:

componentDidMount() {
    fetch(this.getAuth())
      .then(auth => {
          if (auth) this.checkAuth(auth)
      })
}

Answer 4

When you use componentDidMount without async keyword, the doc say this:

You may call setState() immediately in componentDidMount(). It will trigger an extra rendering, but it will happen before the browser updates the screen.

If you use async componentDidMount you will loose this ability: another render will happen AFTER the browser update the screen. But imo, if you are thinking about using async, such as fetching data, you can not avoid the browser will update the screen twice. In another world, it is not possible to PAUSE componentDidMount before browser update the screen

Answer 5

I think it's fine as long as you know what you're doing. But it can be confusing because async componentDidMount() can still be running after componentWillUnmount has run and the component has unmounted.

You may also want to start both synchronous and asynchronous tasks inside componentDidMount. If componentDidMount was async, you would have to put all the synchronous code before the first await. It might not be obvious to someone that the code before the first await runs synchronously. In this case, I would probably keep componentDidMount synchronous but have it call sync and async methods.

Whether you choose async componentDidMount() vs sync componentDidMount() calling async methods, you have to make sure you clean up any listeners or async methods that may still be running when the component unmounts.

Answer 6

Update:

(My build: React 16, Webpack 4, Babel 7):

When using Babel 7 you'll discover:

Using this pattern...

async componentDidMount() {
    try {
        const res = await fetch(config.discover.url);
        const data = await res.json();
        console.log(data);
    } catch(e) {
        console.error(e);
    }
}

you will run into the following error...

Uncaught ReferenceError: regeneratorRuntime is not defined

In this case you will need to install babel-plugin-transform-runtime

https://babeljs.io/docs/en/babel-plugin-transform-runtime.html

If for some reason you do not wish to install the above package (babel-plugin-transform-runtime) then you will want to stick to the Promise pattern...

componentDidMount() {
    fetch(config.discover.url)
    .then(res => res.json())
    .then(data => {
        console.log(data);
    })
    .catch(err => console.error(err));
}

Answer 7

I like to use something like this

componentDidMount(){
   const result = makeResquest()
}
async makeRequest(){
   const res = await fetch(url);
   const data = await res.json();
   return data
}

Answer 8

Actually, async loading in ComponentDidMount is a recommended design pattern as React moves away from legacy lifecycle methods (componentWillMount, componentWillReceiveProps, componentWillUpdate) and on to Async Rendering.

This blog post is very helpful in explaining why this is safe and providing examples for async loading in ComponentDidMount:

https://reactjs.org/blog/2018/03/27/update-on-async-rendering.html

Answer 9

To Tag on to @C-F's answer, I added a typescript decorateor (AsyncMethodErrorHandler) to handle errors in async componentDidMount() and other async methods that fail to bubble up errors to the application state.

I found this easier than wrapping dozens of async methods in a try/catch block in an app whose maintainince I inherited.

class BuggyComponent extends React.Component<{error_message?:string}> {

  @AsyncMethodErrorHandler("error_message")
  async componentDidMount() {
      await things_that_might_fail();
  }

  render(){
      if(this.state.error_message){
          return <p>Something went wrong: {this.state.error_message}</p>
      }
  }
}


function AsyncMethodErrorHandler(
  /* Key in the this.state to store error messages*/
  key: string,
  /* function for transforming the error into the value stored in this.state[key] */
  error_handler: string | { (e: Error): string } = (e: Error) => e.message
) {

  return function (
    cls: React.Component,
    propertyKey: string,
    descriptor: PropertyDescriptor
  ) {
    const f: { (...args: any[]): Promise<any> } = descriptor.value;
    return {
      ...descriptor,
      value: function (...args: any[]) {
        return f.apply(this, args).catch((e: Error) => {
          console.log(`an error occured in the ${propertyKey} Method:`, e);
          (this as any as React.Component).setState({
            [key]:
              typeof error_handler === "string"
                ? error_handler
                : error_handler(e),
          });
        });
      },
    };
  };
}

Note that as of this writing, this solution does not work for async function properites because:

property decorator[s] can only be used to observe that a property of a specific name has been declared for a class