Hacker News Reader

Comment by hiphipjorge | Hacker News Reader

What the hell is this?

  export default function getUsers () {
    return new Promise((resolve, reject) => {
      getUsers().then(users => {
        filterUsersWithFriends(users)
        .then(resolve)
        .catch((err) => {
          resolve(trySomethingElse(users));
        });
      }, reject)
    });
  }

There is never a need to write this type of terrible code if you're using promises. The solution this is not async/await. I agree that async/await and generators are nice, but saying they solve a problem that is not actually a problem seems a little silly.

This is typical of many technical blog posts: Overcomplicate a solution that could be done much more cleanly and clearly in order to show off a new feature, when in reality that feature is actually not that useful.

View on HN

And the "correct" code would be this for instance:

  export default function getUsers () {
    return getUsers().then(users => {
      return filterUsersWithFriends(users)
        .catch(err => trySomethingElse(users));
    });
  }

Or if you like one-liners:

  export default function getUsers () {
    return getUsers().then(users => filterUsersWithFriends(users).catch(err => trySomethingElse(users)));
  }

(EDIT: ahem, that'll teach me to not look at the code I'm editing)

I dont think this quite works. For one thing, the users references won't be available when you try to use it in trySomethingElse(users), because it's scoped to that little arrow function above. For another, it has the effect of catching any error thrown by getUsers() and calling trySomethingElse, whereas the original code simply did nothing in that case.

This isn't correct, `users` would be undefined.

That still doesn't look as nice as await.

You're still nesting. Considering the whole point the author made was that something went wrong with `filterUsersWithFriends`, then you would simply handle that in the next `.then`... So something like:

  export default function getUsers () {
    return getUsers()
      .then(users => filterUsersWithFriends)
      .then(getUsersLikes, trySomethingElse);
  }

would have been more than enough.

I think the problem with your solution is that trySomethingElse won't have access to the users variable unless the filterUsersWithFriends rejection explicitly passes it through.

Been using async/await like sweetjs macro "task" in production for around 1.5yrs (https://github.com/srikumarks/cspjs). This code would read -

    task getUsersWithFriends() {
        users <- getUsers();
        catch (e) {
            return trySomethingElse(users);
        }
        // Everything below is protected by the catch above.
        withFriends <- filterUsersWithFriends(users);
        return withFriends;
    }

.. with errors propagating to nodejs style callbacks automatically. No need for overheads like "promisifyAll" either. cspjs turns the task into a state machine. Better semantics for catch and finally where you can retry operation from within catch clause (ex: exponential backoff).

disclosure: author of cspjs. couldn't help shameless plug since this was being touted as the "future" in the original post!

This has a name, and apparently a lot of people do it stackoverflow.com/questions/23803743/what-is-the-explicit-promise-construction-antipattern-and-how-do-i-avoid-it/23803744#23803744

I much rather write coffeescript, but at least I can understand the code much better this way and it is not such an abomination.

    await getUsers(), defer err, users
    return cb err if err?
    
    await filterUsersWithFriends users, defer err, users
    return cb err, users

I seriously don't get how people like Javascript when to do such a simple things you need so much code that looks so ugly (IMO).

This is how I've been writing Iced Coffeescript for years. I still believe it's a major improvement over the typical promise syntax.

And to make the error handling even cleaner, check out the errify/errorCallback pattern:

http://maxtaco.github.io/programming/2014/09/18/handling-err...

https://www.npmjs.com/package/errify

https://github.com/nextorigin/express-rendertype/blob/master...

Hm, looks interesting. I wonder if it would be possible to monkey-patch the defer itself in something like this. So that defer itself is handling it, but only if you do the the monkey-patching per file and not globally.

   defer = require 'defer-esc'
   await req.get 'https://x.io', defer err, http, res # if err will call cb err
   await req.get "https://x.io?hash=#{res.hash}", defer err, http, res # if err will call cb err
   return cb res

Reply on news.ycombinator.com