How to use async await elegantly in JS

jQuery's $.ajax
The beginning of the Webpack era
A Deeper Look at Promises
Eliminate nesting
await-to-js
Summarize

jQuery's $.ajax

Before we start, let's talk about my js asynchronous journey. When I was still in school, jQuery was still the king. The asynchronous operation that I came into direct contact with and used most often was network request. I used $.ajax to go around the world, and it accompanied me from my sophomore year to almost half a year after graduation.

$.ajax( "/xxx" )
  .done(function() {
    // success !!! do something...
  })
  .fail(function() {
    // fail !!! do something...
  })
  .always(function() {
    // loading finished..
  });

It is undeniable that $.ajax is quite useful. In most scenarios where there is only one request, it is fully competent and even great.

But there is a big problem, that is, it will be extremely annoying when facing a request chain. For example, if one request depends on the result of another request, two may not matter, but if there are five or eight, you may want to commit suicide. . .

$.ajax('/xxx1')
  .done(function() {
    // success !!! do something...
    $.ajax('/xxx2')
      .done(function() {
        // success !!! do something...
        $.ajax('/xxx3')
          .done(function() {
            // success !!! do something...
            $.ajax('/xxx4')
              .done(function() {
                // success !!! do something...
                $.ajax('/xxx5')
                  .done(function() {
                    // success !!! do something...
                    // more...
                  })
                  .fail(function() {
                    // fail !!! do something...
                  })
                  .always(function() {
                    // loading finished..
                  });
              })
              .fail(function() {
                // fail !!! do something...
              })
              .always(function() {
                // loading finished..
              });
          })
          .fail(function() {
            // fail !!! do something...
            $.ajax('/xxx6')
              .done(function() {
                // success !!! do something...
                $.ajax('/xxx7')
                  .done(function() {
                    // success !!! do something...
                    // more....
                  })
                  .fail(function() {
                    // fail !!! do something...
                  })
                  .always(function() {
                    // loading finished..
                  });
              })
              .fail(function() {
                // fail !!! do something...
              })
              .always(function() {
                // loading finished..
              });
          })
          .always(function() {
            // loading finished..
          });
      })
      .fail(function() {
        // fail !!! do something...
      })
      .always(function() {
        // loading finished..
      });
  })
  .fail(function() {
    // fail !!! do something...
  })
  .always(function() {
    // loading finished..
  });

Sorry, I didn't know you could layer it so many times. . . , but the fact is that such processes often occur in TM. Tell me, this cannot be blamed on the product, right? ? ? I can only blame myself for not being good at learning

I think anyone would be frustrated by chain operations like this. Let's not talk about the readability of the code. Take the product requirements that change every day. Maybe request 1 was followed by request 2 and request 3. Later, the product manager decided that the process was not right, so it became request 2, request 3, and request 1. How can we change this? Some people may wonder, why not use axios, await, and async? It has to be mentioned that the project code is JSP written in 2008. . . . After shitting for more than half a year, a big turnaround came. The new projects I wrote started to switch to Vue and gave up some compatibility, and I took off immediately. . .

The beginning of the Webpack era

The new project is Vue + Webpack. I directly arranged axios, await, and async. Now the code is very easy to use, and there is no more nested N layers of code.

const r1 = await doSomthing1();
if (r1.xxx === 1) {
  const r2 = await doSomthing2(r1);
  const r3 = await doSomthing3(r2);
  // do something....
} else {
  const r4 = await doSomthing4(r1);
  const r5 = await doSomthing5(r4);
  // do something....
}
// do something....

But there is a problem with the above code. If a task reports an error, the code will terminate directly. . . This does not meet our expectations, so let's add try catch

let r1;
try {
  r1 = await doSomthing1();
} catch (e) {
  // do something...
  return;
}
if (r1) {
  if (r1.xxx === 1) {
    let r2;
    try {
      r2 = await doSomthing2(r1);
    } catch (e) {
      // do something...
      return;
    }
    if (r2) {
      let r3;
      try {
        r3 = await doSomthing3(r2);
      } catch (e) {
        // do something...
        return;
      }
      // do something...
    }
  } else {
    let r4;
    try {
      r4 = await doSomthing4(r1);
    } catch (e) {
      // do something...
      return;
    }
    if (r4) {
      let r5;
      try {
        r5 = await doSomthing5(r4);
      } catch (e) {
        // do something...
        return;
      }
    }
    // do something...
  }
  // do something...
}

? ? ?

Optimized, the same as not optimized. . .

At this point, I think smart friends might ask, what kind of pancake is this? And the dull friends have already started thinking about how to solve this problem. . .

A Deeper Look at Promises

Let's look at the definition of Promise

/**
 * Represents the completion of an asynchronous operation
 */
interface Promise<T> {
    /**
     * Attaches callbacks for the resolution and/or rejection of the Promise.
     * @param onfulfilled The callback to execute when the Promise is resolved.
     * @param onrejected The callback to execute when the Promise is rejected.
     * @returns A Promise for the completion of which ever callback is executed.
     */
    then<TResult1 = T, TResult2 = never>(onfulfilled?: ((value: T) => TResult1 | PromiseLike<TResult1>) | undefined | null, onrejected?: ((reason: any) => TResult2 | PromiseLike<TResult2>) | undefined | null): Promise<TResult1 | TResult2>;

    /**
     * Attaches a callback for only the rejection of the Promise.
     * @param onrejected The callback to execute when the Promise is rejected.
     * @returns A Promise for the completion of the callback.
     */
    catch<TResult = never>(onrejected?: ((reason: any) => TResult | PromiseLike<TResult>) | undefined | null): Promise<T | TResult>;
}

Then and catch will both return a new Promise. I believe many of you have already figured out how to solve this problem. We need to use try catch because it will report an error. So why don’t we just return a result that will never report an error? Just do it

Eliminate nesting

function any(promise) {
  return promise.then((v) => v).catch((_) => null);
}

Is this completely solved? ? ? By judging whether there is a value to determine whether it is successful, there is no need to write try catch, but such code is a bit difficult to use. If then returns a void, then it is finished. One is undefined and the other is null. It is useless to judge. Let's improve it.

function any(promise) {
  return promise
    .then((v) => ({ ok: v, hasErr: false }))
    .catch((e) => ({ err: e, hasErr: true }));
}

Use words

const r = await any(doSomething());
if (r.hasErr) {
  console.log(r.err);
  return;
}
console.log(r.ok);

Doesn’t it look perfect now? Let’s promote it to our friends right away.

Friend:? ? ? What kind of pancake is this? I don’t need it.

Me: I wrote this. It works very well in asynchronous environments. No need to nest try catch or anything like that. . .

Friend: Okay, I’ll use it next time.

Everyone must have encountered such a situation, where everyone looks down on each other's code, and as long as it is not a third-party library, everyone will not use it if possible. . .

await-to-js

I thought I was the only one who appreciated this elegance. Things took a turn for the better. One day, I was browsing GitHub and found something similar to mine, await-to-js. A few lines of code revealed the same obsession as mine.

// Below is the latest code/**
 * @param { Promise } promise
 * @param { Object= } errorExt - Additional Information you can pass to the err object
 * @return { Promise }
 */
export function to<T, U = Error> (
  promise: Promise<T>,
  errorExt?: object
): Promise<[U, undefined] | [null, T]> {
  return promise
    .then<[null, T]>((data: T) => [null, data])
    .catch<[U, undefined]>((err: U) => {
      if (errorExt) {
        Object.assign(err, errorExt);
      }

      return [err, undefined];
    });
}

export default to;

Then paste the usage example

import to from 'await-to-js';
// If you use CommonJS (ie NodeJS environment), it should be:
// const to = require('await-to-js').default;

async function asyncTaskWithCb(cb) {
     let err, user, savedTask, notification;

     [ err, user ] = await to(UserModel.findById(1));
     if(!user) return cb('No user found');

     [ err, savedTask ] = await to(TaskModel({userId: user.id, name: 'Demo Task'}));
     if(err) return cb('Error occurred while saving task');

    if(user.notificationsEnabled) {
       [ err ] = await to(NotificationService.sendNotification(user.id, 'Task Created'));
       if(err) return cb('Error while sending notification');
    }

    if(savedTask.assignedUser.id !== user.id) {
       [ err, notification ] = await to(NotificationService.sendNotification(savedTask.assignedUser.id, 'Task was created for you'));
       if(err) return cb('Error while sending notification');
    }

    cb(null, savedTask);
}

async function asyncFunctionWithThrow() {
  const [err, user] = await to(UserModel.findById(1));
  if (!user) throw new Error('User not found');
  
}

Does the feeling come back, no longer nested? . .

In order to let my friends use the previous line of code, I can only reluctantly recommend await-to-js and post it on github. My friends: more than 800 stars (ps: now 2K+) The quality is reliable. I took a look at the examples. Well, it’s very good and perfect. I’ll go back to the next one. . . I don’t need to say much about what happened next. I also replaced all my own code with await-to-js. . .

I treat the world like my first love, but my first love hurts me thousands of times

Summarize

The version I implemented actually has some problems. In a flexible language like JS, if I change the return value, others can just copy my version. The type is not strict enough. If it is put in TS, it can only be said to be a minor problem. The newly added ok, err, hasErr adds a little case, but it is not fatal.

The little bit of design philosophy in await-to-js, why the error is placed in the first position of the array instead of the success, is very clear: always remember the mistakes, put the mistakes first, instead of being confident in success and forgetting the pain of mistakes.

const [, result] = await to(iWillSucceed());

References

$.ajax
Promises
await-to-js

This is the end of this article about how to use async await elegantly in JS. For more information about how to use async await elegantly in JS, please search for previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope you will support 123WORDPRESS.COM in the future!

You may also be interested in: