Hacker News Reader

Comment by nailer | Hacker News Reader

Short ver: async await is now in an LTS release of node. Anything that returns a promise can now be run inline - ie, no endless .then() chaining - provided you've started an async context:

  const writeFile = util.promisify(fs.writeFile),
    request = util.promisify('superagent'),
    stat = util.promisify(fs.stat),
    sorts = require('sorts'),
    log = console.log.bind(console)

  const getJeansAndSaveThem = async function(){ 
    var jeans = await request.get('https://example.com/api/v1/product/trousers').query({
      label: 'Levi Strauss', 
      isInStock: true,
      maxResults: 500
    }).end()
    jeans = jeans.sort(sorts.alphabetical)
    await writeFile('jeans.json', jeans)
    const status = await stat('jeans.json');
    log(`I just got some data from an API and saved the results to a file. The file was born at ${status.birthtime}`)
  }

Note: you should add error handling, I'm new to async/await and this code is to demonstrate a concept on HN, not to run your life support system. ;-)

View on HN

As noted, this already was possible in Node 7.x. But to use it, you needed a function that returned a promise. And many functions do not, due to having been developed earlier. This is true even for libraries done in 2016. Even today many Node.js developers don't seem to use async/await. At least in my country... And thus they live in braces {} hell.

The improvement on the 8.0.0 version is that such an "oldie" function can be Promisified. A great improvement.

By "oldie" function, do you mean functions that expect node-style callbacks?

  e.g. function myCallback (err, result) {...}

Correct. Most node core APIs are written this way and now core ships an utility function[0] to wrap those functions in a promise.

[0]: https://medium.com/@styfle/promises-in-node-js-8-x-core-d6a8...

It seems to me that Node should ship promisify-ed versions of all these functions (e.g. fs.readFileAsync). Over time they could replace the implementation with ones that use the OS Async APIs, though perhaps this step is unnecessary if you're already using an event loop underneath.

Until then you can use `mz` for a modernised API[0].

[0] https://github.com/normalize/mz

I mean, they've been debating about how to add a promisified API for years (see for example https://github.com/nodejs/node/pull/5020) but nothing has come of it. util.promisify is a welcome addition, but very late for a first step.

How incredibly uncanny. Just yesterday morning, I posted this question!

https://stackoverflow.com/questions/44260289/using-native-es...

You could always promisify functions manually, or with this tiny package https://github.com/sindresorhus/pify but yeah it's nice to see that in the standard library.

util.promisify is now in Node core as shown in the Original Comment

FWIW v8.0.0 is not an LTS release. Technically the first v8.x LTS release will happen in October. See this repo for more details: https://github.com/nodejs/lts

Async/await support (without the --harmony flag) was made default in version 7.6 when they updated V8 to version 5.5.

The biggest additions here with regard to async/await is the new promisify util and the async_hooks.

Edit: Changed wording and included more detail.

Of course, but most people don't run non-LTS node releases :-)

Edit: originally wrote 'unstable'. Meant 'non-LTS'

Node 7.6 is a stable release. Are you talking about LTS?

The 7.6 release was no more unstable than the 8.0 release. Unless you're referring to the fact that 8.0 is going to be a LTS release. But if that's the case, it's not happening for a while yet, 6.10 is still the current LTS version.

You're right, corrected.

And some performance improvements. And the fact that there are more to come when they upgrade to V8 5.9 soonish.

>request = util.promisify('superagent')

I don't think that's required. Superagent already returns promises.

Ah you're right!

https://visionmedia.github.io/superagent/#promise-and-genera...

Alas too late to edit comment.

Sure, but having `util.promisify` in core modules means you no longer need an external dependency here.

Hm? It's not an external dependency. Superagent returns a promise.

Replying to myself: since this comment is so popular, here's a fully working version for node 8:

  const util = require('util'),
    fs = require('fs'),
    writeFile = util.promisify(fs.writeFile),
    request = require('superagent'),
    stat = util.promisify(fs.stat),
    sorts = require('sorts'),
    log = console.log;

  const getPhotosAndSaveThem = async function(){
    try {
      const response = await request.get('https://jsonplaceholder.typicode.com/photos');
      const photos = response.body.sort(sorts.byKey('title'))
      await writeFile('photos.json', JSON.stringify(photos, null, 2))
      const status = await stat('photos.json');
      log(`I got some data from an API and saved the responses at ${status.birthtime}`)
    } catch (e) {
      log(`Oh no, something went wrong!`, e)
    }
  }

  getPhotosAndSaveThem()

Is there a roadmap for supplying async/await interfaces for the entire stdlib? Still some event/callback based stuff in there that doesn't return promises or conform to the callback standard promisfy requires.

Yeah, most of the time, I need to handle errors with try/catch block.

rant: why care about debugability and testability

There should also be something like

  awaitAll

to replace

  await Promise.all

calls.

You can make it yourself fairly easily I guess:

    const awaitAll = Promise.all.bind(Promise);

    async function foo() {
        var [val1, val2] = await awaitAll([func1, func1]);
    }

It isn't ideal but it's a little cleaner

+1. I'm a big fan of top level function binds to remove boilerplate and keep code readable:

  const log = console.log.bind(console), 
    query = document.querySelector.bind(document),
    queryAll = document.querySelectorAll.bind(document);

You don't need to bind `console.log` by the way (at least not in any recent version of Node.js or browsers).

  await all([fn1, fn2]) ;)

i wonder when we will get s-expressions for function calls

  (awaitAll [fn1, fn2])

Just write (iced) coffeescript, s-exp are totally valid there:

https://github.com/nextorigin/riemann-query-parser/blob/mast...

Yeah, s-exps are the only thing I miss :(

There are many ways to compose promises, no point in elevating some of them to keyword status. If you need to do anything interesting with promises, just use a promises library. The point of async/await is to free you from having to use callbacks, not to eliminate the need for libraries.

Every async function will return a Promise anyway. I am simply interested in resolving a collection of Promises in a clean way.

Given Promise.all resolves to an ordered array surely this would work:

    const [foo, bar, baz] = await returnerOfPromiseCollection();

That would assume there was either a) a catch in that collect or b) some error checking, but still...

It "works" but foo won't contain the resolved value, just the promise.

The code is awaiting an array, which is already "resolved" and its returned right away. Its contents are not relevant to `await`.

You are correct! My apologies = I misremembered how that works >_<

Yes, once you have a promise you have to deal with it as such through the whole chain.

I don't see what's unclean about Promise.all or how creating a 1:1 alias for it makes it cleaner.

Also, many times you want to limit the concurrency of your promise execution which isn't something you can do with an array of promises. You'd be back to using `await` + something like https://www.npmjs.com/package/promise.map.

I'm someone that used to use `co` where you could go:

    const [a, b] = yield [promiseA(), promiseB()]

But I prefer the simplicity and consistency of having to use something like Promise.all or require('promise.map').

Its the ambiguity for new programmers. With something like awaitAll new programmers wouldn't need to learn about Promises at all.

You have a point with concurrency, but handling concurrency is an another beast altogether.

I have a hard time understanding how adding alias indirection disambiguates anything much less spares one from learning something.

How does one get to the point where they want to await multiple promises, yet they need to be insulated from the very presence of the `Promise` object?

Well at least in my mental model a Promise is an object that eventually resolves to something within its .then() method. In contrast my mental model of await is that of a blocking call. One can internalize the latter without the former.

Promise.all is not even that good. If one fails, the rest of the Promises are lost. It does not wait for all Promises.

I prefer something like p-settle most of the time https://github.com/sindresorhus/p-settle

Pretty sure there used to be a syntax in the spec for handling that. Something like `await*` I believe. It got removed pretty early on in the process though.

Any interesting reasons as to why?

I wasn't really involved in those discussions, but I suspect it's for similar reasons to what others in the comments here are arguing; they wanted to keep the syntax minimal and decided that adding a special syntactic sugar for something that could already be accomplished by `Promise.all(...)` was unnecessary.

You can use .map to call await on every element in the array, or define a new function so you don't have to write that all the time:

    const awaitAll = (futures) => futures.map(f => await f);

edit: this is wrong but I can't delete it. Haven't used async as much as promises.

Don't you need to be in an async context to call await?

Well an async function always returns a Promise. await simply blocks until the Promise is resolved to continue execution. Thats why I am wondering why they decided to await only on a single Promise.

Async await being part of core, not behind a flag, is probably my favorite new addition.

1) This was possible in node 7

2) A request can fail and can timeout.

3) Writing to a file can fail.

And you get the idea. Don't omit error handling. Error handling is business logic too.

Being relaxed around error handling is the recipe for cascading server failure.

I'm just getting started with async/await (like most people I stick to LTS releases) so please forgive the lack of error handling in the demo code!

As someone who spends all day volunteering in Stack Overflow I hope people providing examples were a little bit better at emphasizing error handling.

You should see the destructive effects of bad examples there.

You're welcome to add it.

Oh please. The point of the post was to illustrate the feature to those wondering "what's async/await?", error handling would be complete noise for that purpose.

I would argue with you, but I don't really have to prove you wrong.

You will eventually prove yourself wrong, since deemphasizing error handling goes wrong very quickly.

In their snippet, errors would be handled altogether on the promise you get from `getJeansAndSaveThem()`.

You don't have enough information to be outraged at the toy example.

And that's a very implicit way of handling the error. Implicit behavior is good when you are encapsulating stuff (e.g: I don't need to know about the details of internal combustion engines, just pushing on the accelerator of my car so it moves forward).

But in this case encapsulation is a leaky abstraction that just makes the diagnosing of an error more cumbersome.

Note that node 8.0.0 is not LTS. Node 8.x will be an LTS release around October.

One of the nice things is that you can just let async functions fail and they won’t throw asynchronously and kill the process. So no, error handling isn’t important to include in a small example.

Previously that characteristic was also a massive pain point for debugging Node apps though - neglecting error handling would result in silently swallowed errors and leave people (particularly newbies) scratching their heads.

Then they added unhandled rejection warnings by default, and all was ok again - but I see why someone might insist that all examples have error handling.

That’s not something that should be handled inside an async function (and therefore not in this example). If you don’t want to continue a promise chain, terminate it:

  .catch(error => {
    process.nextTick(() => { throw error; });
  })

You want to use setImmediate rather than process.nextTick.

Mmm… no, I didn’t want to. Why do you say that?

Obviously the example code is inside another function - `await` can only be used inside a function marked with `async`, which always returns a promise.

That means error handling may not be necessary inside that function. Errors are caught automatically and returned to the caller as rejected promise! You need error handling at the top level but not necessarily inside each function.

Reply on news.ycombinator.com