DEV Community

Why async code is so damn confusing (and a how to make it easy)

JavaScript Joel on September 24, 2018

Why is asynchronous code in Javascript so complicated and confusing? There are no shortage of articles and questions from people trying to wrap t...

Read full post

Yuri • Sep 25 '18

Great article, I stubble with the same issues a while back, and started using github.com/fluture-js/Fluture it basically transforms promises into monads, something like:

const Future = require('fluture')
const { compose, map } = require('ramda')

const greet = name => Future.of(`Hello ${name}`)
const exclaim = line => Future.of(`${line}!`)
const trace = x => console.log(x)

// With function composition (Ramda)
const sayHello = compose(
  map(trace),
  map(greet),
  exclaim
)
sayHello("bob").fork(console.error, console.log)

I convert all my promises to futures, if it fails instead of catching the error, the map will not be triggered and I can use mapRej to deal with the error

JavaScript Joel • Oct 11 '18

fluture is one of those project I have read about, always wanted to use and have never used. I need to block out some time and just use it one day. I feel like even if I don't end up using it I will learn a lot.

Jochem Stoel • Sep 24 '18

/* moji.js */
const pipe = require('mojiscript/core/pipe')
const fs = require('fs')

const syncMain = pipe([
    file => fs.readFileSync(file, 'utf8'),
    console.log
])
const asyncMain = pipe([
    file => fs.readFile(file, 'utf8'),
    console.log
])

syncMain('moji.js')
asyncMain('moji.js')

Output

> node moji.js
const pipe = require('mojiscript/core/pipe')
const fs = require('fs')

const syncMain = pipe([
    file => fs.readFileSync(file, 'utf8'),
    console.log
])
const asyncMain = pipe([
    file => fs.readFile(file, 'utf8'),
    console.log
])

syncMain('moji.js')
asyncMain('moji.js')
(node:7424) UnhandledPromiseRejectionWarning: TypeError [ERR_INVALID_CALLBACK]: Callback must be a function
    at maybeCallback (fs.js:129:9)
    at Object.readFile (fs.js:275:14)
    at file (C:\Users\Gebruiker\Desktop\moji.js:10:16)
    at process._tickCallback (internal/process/next_tick.js:68:7)
    at Function.Module.runMain (internal/modules/cjs/loader.js:745:11)
    at startup (internal/bootstrap/node.js:279:19)
    at bootstrapNodeJSCore (internal/bootstrap/node.js:752:3)
(node:7424) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:7424) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

JavaScript Joel • Sep 24 '18

One change you'll have to make is to convert all callback-style functions into promise-style functions.

In this case fs.readFile is a callback-style function.

You can convert it using node's util.promisify function like this:

import fs from 'fs'
import { promisify } from 'util'

// Asynchronous file reader
const readFile = promisify(fs.readFile)

Now you can use your promise-style function in the pipe.

Jochem Stoel • Sep 24 '18

My bad, I should have seen that.

Intrigued. I have a strongly opinionated post draft saved that is spooky similar to what I read from you today. Asking the same questions providing the same examples. I will have a more interested look at your emoji package and the patterns you are adopting.

JavaScript Joel • Sep 24 '18

I'm guessing you are like me and have about a dozen articles in the 90% finished draft state?

Can't wait to see what you are working on!

Jochem Stoel • Sep 25 '18

Although the notation would not be identical. Another thing you can do is write a single function to handle both sync and async and deciding which by its arguments. Asynchronous if a callback is provided, otherwise synchronous.

/* synchronous return */
readFile('file.txt')

/* asynchronous, no return value */
readFile('file.txt', console.log)

crazy4groovy • Sep 27 '18 • Edited

There's one thing to recognize about await, is that it doesn't "hurt" anything!

So:

const main = async () => {
  action1()
  await sleep(1000)
  action2()
}

and

const main = async () => {
  await action1()
  await sleep(1000)
  await action2()
}

will always be the same.

In fact, event if action1 and action2 returns a literal value (let's say "hi!"):

const main = async () => {
  const a = action1()
  await sleep(1000)
  const b = action2()
  console.log(a, b)
}

and

const main = async () => {
  const a = await action1()
  await sleep(1000)
  const a = await action2()
  console.log(a, b)
}

will always be the same! (mind. blown.)

I for one think you are onto something, where the lines between async and sync can almost always be blurred away. But I think it would take a new syntax. For example:

const main = () => {
  const a =: action1()
  =: sleep(1000)
  const b = action2()
  console.log(a, b)
}

where =: means "resolve the value", and all arrow function are inherently "async".

(This is kind of like pointer logic, where you either mean "give me the address" or "give me the value at the address"; but here its "give me the promise" or "give me the value of the promise")

JavaScript Joel • Sep 27 '18

That's true, you could just await everything. You can even do this:

const x = await 5

In the case of this problem:

// await `action()`
await thing().action()

// await `thing()`
(await thing()).action()

You could do this and not worry.

// await all the things
await (await thing()).action()

But I would probably go insane.

Vinícius Hoyer • Oct 27 '18

while it is true you could await every thing, there is a difference. the await operator will always wait till the next tick to start checking for the resolving of a promise, even if your promise is a literal. But thats just what I read somewhere that I don't remember where, sorry for the lack of reference, yet I'm pretty confident in the information.

JavaScript Joel • Oct 27 '18

I believe you were correct about this. Adding extraneous awaits could have a performance impace.

Dan Fockler • Sep 24 '18

This looks pretty neat. Having worked with async code before Promises were everywhere, they are a real trip to learn to use. Although the idea is used throughout the programming stack, it's definitely something useful to learn.

I think the coolest part of async/await style is that you can use try/catch to get errors instead of having to add a new function for every promise you unwrap.

JavaScript Joel • Sep 24 '18

Haha that's interesting! That was actually the main reason I disliked async/await, I had to wrap everything in a try/catch.

Guess it all depends on what your preferences are.

Ben Halpern • Sep 24 '18

Wow, Mojiscript looks really well-done. I'm following along now 😄

JavaScript Joel • Sep 24 '18

Thanks! I have been writing functional code for a while now, but I my style and tools has been evolving and I have never laid out a style guide or any rules to follow. So each project tends to be a little different.

This is the first time laid out some rules. Putting in that extra time to create the guide and readme really helped me solidify some thoughts in my head. I think it came out well and I hope to produce some projects that can showcase the language.

Appreciate you taking a peek at it :)

Cheers!

Ben Halpern • Sep 24 '18

Are you (or anyone else) using Mojiscript in production?

JavaScript Joel • Sep 24 '18

Great question. I wouldn't recommend it for production. I created it less than 2 weeks ago and haven't finalized the API.

I would expect the interface and behavior to change based on feedback. I would consider this version a developer preview.

I am using this framework for a few pet projects of mine that I will open source when ready :)

Ben Halpern • Sep 24 '18

That's what I figured, but it's well-polished in the presentation that I wasn't quite sure.

JavaScript Joel • Sep 24 '18

lol ya thanks!

but again great question. I'll make this more clear in this article so people don't go launching this into prod yet!

Need more testers. Currently at zero. lol

Tomer Ben David • Oct 2 '18 • Edited

What about debugging it in most cases although the syntax makes it easy I'm not sure about debugging...

JavaScript Joel • Oct 2 '18

You actually have less debugging because all of your functions become testable.

Try unit testing this:

for (var i = 1; i < 6; i++) {
  setTimeout(() => console.log(i), 1000)
}

hint: it sucks.

Scott Hannen • Sep 25 '18

This should definitely be added into CoffeeScript.

JavaScript Joel • Sep 25 '18

You should be able to import pipe into coffee script!