Hacker News Reader

Comment by Aeolun | Hacker News Reader

   const myfunc = () => new Promise(resolve => resolve())

Is there anyone that actually likes this structure? I find it really hard to reason about what a line like this does. What is the upper limit on double arrows in one line?

View on HN

here's a real world example I use all the time:

    const wait = (ms = 500) => new Promise(resolve => setTimeout(resolve, ms));

then:

    async function () {
      await wait(1000);
    }

Perhaps it's hard to grok but it sure is a handy one-liner.

Of course in newer versions of node we can now do:

    import {
      setTimeout,
    } from 'timers/promises';

    await setTimeout(100);

There's no merit of what should be a project wide function being a single line instead of 3 to avoid "hard to grok" syntax.

Wait till you see the rest of javascript...

Your comment is snarky and categorically dismissive. Care to explain why you have taken such an aggressive stance against JS?

this works in older versions of node too:

const wait = require(‘util’).promisify(setTimeout)

but not in the browser

It’s the cleanest way to wrap a event-emitting library, for example. async/await is not applicable in such a case where resolve needs to be explicitly called in a callback.

    async function process() {
      return new Promise((resolve, reject) => {
        emitter.on(”error”, (err) => reject(err));
        emitter.on(”end”, (result) => resolve(result));
        emitter.start();
      });
    }

async is not strictly needed here, but I find it a good practice to use it on functions which immediately return a Promise anyway.

I don't think it's a good practice, atleast if you have typescript jn your stack. It's redundant and wraps the promise in another promise.

IIRC that doesn’t actually happen if a native Promise is returned.

It does, but only if you also add a redundant await. Which I still do, even in TypeScript, unless there’s a compelling performance reason not to. I disagree with the article overall, but I do agree that making asynchrony as explicit as possible is a good idea. Otherwise you end up with code like:

  async function foo(bar) {
    // ...
  }

  function nonObviousAsyncFn() {
    // ...
    return foo(quux);
  }

Explicit return types would help, but most people don’t write them unless they’re forced by a linter.

This would still return a promise for both functions. My IDE at least is really obvious about what happens.

Yes, this is a common anti-pattern

    return await foo();

Your gripe is that there are two arrows on one line? The second is an argument to the promise constructor. You should be able to reason about this line easily.

I think I was unclear. Of course you can figure out what the line does. It’s just that you have to figure it out.

If the implication is not that the "double arrows" are tripping you up, then yes you were unclear.

Reply on news.ycombinator.com