Cleaning up your asynchronous code with
REPLs have traditionally had a difficult time allowing you to interact with asynchronous code since they encourage a coding style where you evaluate expressions and use those results in the next field. But if you are using promises or callbacks, this breaks down because these results exist only in the callback, not the next line:
In RunKit, you can use top-level
await to get the same behavior of synchronous code.
Now we can treat this code as synchronous, despite the fact that the code is still executing asynchronously.
Let's look how. It helps to have a more complex example, where we need to do a few asynchronous operations in sequence. You can see how
await, promises and callbacks achieve the same results, but the
await style works better in a REPL:
Here, we use
await on lines 4 and 8, and the results from each request remain in scope.
Promises appear to be cleaner than nested callbacks, but not without a new syntax and scope confusion caused by passed functions.
When using callbacks, the error, body and response are only in the callback's scope, so we nest a second callback to perform another
got call using data returned from the first.
await expects a
promise so you can either write your own or use one of the many libraries that natively supports promises, and npm is full of packages that add promise support to existing libraries. Here are a few of our favorites:
- fs-promise - promise based filesystem api
- request-promise - a wrapper around "request" for http stuff
- glob-promise - glob style filesystem queries
- bluebird - general promise library with lots of utilities