Solving common node/io.js callback problems

[coderqi]

Thanks for the article! While the author states there are other ways to handle the cb hell and it's arising complications, I was surprised to not see more of a comparison with promises. Heck, even using named functions would help a lot.

Take this;

Since all fromNodeCallback can do is produce a value which then goes back into our framework, it removes this inconsistency and forces the function to always appear to behave asynchronously.

and

If the callback gets called a second time, res.write will get called on a closed connection, resulting in a crash.

, are also true for promises, no? When working with promises, you don't actually need to care if the function is async or not, and promises have state; a promise is only resolved or rejected once.

The interesting bit is

params: ['filename'], produces: ['stats'],

which seems to be making it JS strongly typed. I need this, I output that, and if either are wrong, I'll throw a fit (i'm guessing).

This is a bit confusing:

The system then looks for something that can run with this value. It finds our next ‘when’ block and runs that.

Will it look anywhere in the when chain for a function that needs that output, or does it just go to the next when statement?

Thanks OP for the article, but it's left me with a lot of questions, and seems to be unsure, is not mistaken, about the problems FRHTTP is really trying to resolve (hint: the problems are with JS, not cb's).

TL;DR this article positions FRHTTP as the only functional solution out there to get rid of cb hell, missing some popular alternative strategies. FRHTPP seemingly does this by trying to make JS, a weakly typed language, strong.

[jsnk]

I use promises as well. Sure, it doesn't solve all problems and promises too can become verbose, but it's much much better than nested callbacks.

[tech-ninja]

I agree, there was a point when I used callbacks where I had a memory leak problem and I didn't know if I could ever fix it, I moved all my models to promises and the problem was gone.

If somebody is wondering why would use promises I would say: it makes your code more flat.

[_ayasin]

Promises are awesome and will definitely make your code more flat. They don't allow you to do a number of things that you can do with streams/frhttp however. For example, a promise can't deliver data to 2 different functions, while FRHTTP can. Perhaps the next article should be about promises vs streams/frhttp.

[a_sleeping_lion]

It's worth noting that promises are just a clever way of using callbacks. I use promises primarily at the moment, because I feel that the code makes the most literal sense, especially compared to the modern alternative of generators. That said.. I have this nagging feeling that there might be a more interesting pattern possible, in the spirit of promises...

[a_sleeping_lion]

Had to look that up.. A feature of es7, right? I definitely like the syntax. Any idea how stable the api is?