5 ms·

Yes! I wrote about promisify a few weeks ago[0] [0]: https://medium.com/@styfle/promises-in-node-js-8-x-core-d6a8a93e85a2 https://medium.com/@styfle/promises-i

• twii 9y ago
  I still don't get the need for Promises.. Almost all examples, just like this one in the provided link, talk about solving callback hell with Promises, while callback hell is just a bad way of writing software imao. Look at the code below and please tell me why your example with Promises is a better solution. function logAppendResult( err ) { if (err) console.err('Failed to update file'); else console.log('Successfully updated file'); } function logWriteResult( err ) { if (err) console.err('Failed to create file'); else console.log('Successfully created file'); } function handleFile( filename, fileExists ) { const timestamp = new Date().toISOString(); ( fileExists ) ? fs.appendFile( filename, `Updated file on ${timestamp}\n`, logAppendResult ) : fs.writeFile( filename, `Created file on ${timestamp}\n`, logWriteResult ); } function main() { const filename = './example.txt'; exists( filename, (fileExists) => handleFile(filename, fileExists) ); }
  • koolba 9y ago
    Is this a joke? You've repeated the if(err) check in three places. None of your error handling bubbles up so the handlers (i.e. Logging to console.error) are buried in the individual functions. You've pretended to avoid nested callbacks by inlining them using arrow functions. For your sake I hope that was sarcastic.
    • twii 9y ago
      No, it's not a joke. A junior dev can read this code and it will be very hard to create bugs. Inlining with arrows is just a more functional approach, as I would write in Coffee: exists filename, (fileExists) -> handleFile filename, fileExists Anything wrong with that line of code? I just try very hard to keep my code as simple as possible. I hope you know it's trivial to write a log function that accepts different callees so you end up with only 1 'if (err)'. I didn't test, but I wouldn't be surprised if my example runs times faster as well btw.
      • doublerebel 9y ago
        You might like the make_esc/errify pattern [0]. You can apply the same function to any number of error callbacks in order to unify error handling. Works great with Iced CoffeeScript but also works well without. I can provide more examples but I think you'll get it. [0]: https://github.com/nextorigin/el-borracho/blob/master/src/redis-model.coffee#L17 https://github.com/nextorigin/el-borracho/blob/master/src/re... P.S. Iced3 compiles to ES6 await so all of this has been working together for quite a while.
      • koolba 9y ago
        Yes it doesn't handle the error case. And if you replace the if(err) lines with a log(...) function it doesn't reduce them to one place. It makes you repeat the log(...) function everywhere. And you'd still need the if statement to handle the control flow. Simple code is great, but not handling errors doesn't cut it for non throwaway applications.
        • twii 9y ago
          You assume a lot. We can refactor another round: function logFsResult( type, err ){ var msg= ''; switch ( type ) { case 'append': msg= ( err ) ? 'Failed to update file' : 'Successfully updated file'; break; case 'write': msg= ( err ) ? 'Failed to write file' : 'Successfully created file'; break; default: msg= 'logFsResult error, missing or invalid first argument: '+ (type || '') } ( err ) ? console.err( msg ) : console.log( msg ); } function handleFile( filename, fileExists ) { const timestamp = new Date().toISOString(); ( fileExists ) ? fs.appendFile( filename, `Updated file on ${timestamp}\n`, logFsResult.bind(null, 'append') ) : fs.writeFile( filename, `Created file on ${timestamp}\n`, logFsResult.bind(null, 'write') ); }
          • koolba 9y ago
            Honestly that looks hideous.
          • dchest 9y ago
            That's still not error handling, that's error logging. Try writing code that depends on the success of the previous operation to perform another operation and you'll quickly find yourself in the callback soup.
  • floatboth 9y ago
    if (err) console.err('Failed to create file'); Congratulations, you're writing Go in JavaScript! :)
    • twii 9y ago
      nah, this is valid javascript, Go came later, they might have copied a thing or 2 from C, like javascript did.
  • flavio81 9y ago
    Takes a look at the code... logAppendResult almost same as logWriteResult... Well, who are we to deprive you from the joy of writing lots of boilerplate code?
  • ujal 9y ago
    With Promises we conceptualize a control flow construct like callbacks. It is much easier to reason about a concept rather than following code execution paths. With async await we return control flow to the current scope.
  • elmigranto 9y ago
    When callbacks are used with discipline, they are not much different from promises. The problem is when "discipline" part meets "human" part, though it's still true for promises, perhaps to a lesser degree. The real value for promises is async/await.
  • minitech 9y ago
    Have you ever tried to run more than one operation at once and collect the results? (There are lots of other reasons to use the promise abstraction – having a type that can be transformed is extremely useful and natural – but that one’s pretty significant.)
  • rattray 9y ago
    One benefit comes from being able to use `async`/`await`. Using `try`/`catch` with `async`/`await` is a bit awkward, though, which is especially unfortunate because it's the #1 place you should be handling errors. LightScript has a language feature[0] that makes it less awkward (sort of an`Either`/`Result` type) that I'm thinking about submitting to TC39. [0] – http://www.lightscript.org/docs/#safe-await http://www.lightscript.org/docs/#safe-await
  • tlear 9y ago
    I will agree, to be honest I tried promises in my own projects and now writing them for someone. But to me Async.js is just cleaner nicer better. Funniest part is Bluebird docs on transitioning from it to Promises, promise example is bigger and messier.