Check out a free preview of the full Rethinking Asynchronous JavaScript course

The "Non Fixes" Lesson is part of the full, Rethinking Asynchronous JavaScript course featured in this preview video. Here's what you'd learn in this lesson:

Kyle spends a few minutes showing a number of “non fixes” for callbacks. These are techniques that have been developed to make callbacks more reliable, however they tend to introduce their own side effects.


Transcript from the "Non Fixes" Lesson

>> [MUSIC]

>> Kyle: There's a bunch of Non Fixes that have been attempted with callbacks. I call them Non Fixes cuz they're attempts at fixing which actually did nothing but make it worse. So for example, in the callback world we invented this pattern of split callbacks. If our problem that we're trying to solve is that we've got an error that we don't wanna get swallowed in case there's some problem with the main function, we're like I know I'll just pass a separate callback for my errors.

And that way if there is some error at least I know that utility will have some way of notifying me that there was a problem, all right, sounds good on the surface. Until you realize this actually makes the trust issue a lot worse. Because now you have to ask yourself what happens if they call neither of these functions?

What happens if they call both of these functions? Maybe they call the error first and then the success. Or maybe they call the success first and then the error. How is your program gonna handle that? I bet some of you have code like this and you don't have any solution for that yet.

It actually made the problem worse. There's more trust issues. So split callbacks while it sounded good on the servers actually was a regression. It took us away from a good solution. In the node world, we invented what often times referred to as node style, I like to call error first callbacks.

Well let's go back to one callback, two callbacks is crazy. Let's go back to one callback. But we'll reserve the first parameter of that callback for the error signal. So if it's an error that we're signaling, we'll always set that one and nothing else and if it's not an error then we'll leave that.

And so every single node callback that you've ever written has this if else jazz going on in it, where you're checking to see whether or not it's an error condition or not. So it seems like it solved the problem about the split callbacks thing until you realize actually the same questions occur here.

What happens if the utility in question does not behave the way you expect, what happens if it calls your call back twice, once with the air and once with not the error. Or what happens if it calls with both the error and the success parameters, how do you interpret Interpret that situation?

All the same trust issues are at play. We are not fundamentally in control of the callback which means we have inverted all that control and given it away to somebody else. So these are really non fixes. Now I've got a silly running example, how many of you recognize the reference to the meaning of life?

Hopefully I'm not so old that I'm the only one that knows about Hitchhiker's Guide. If you don't know about that, go read Wikipedia, something, get up to speed on it. Silly example calculating the meaning of life using nested callbacks. Here's my think Ajax call, my getData function. As it takes in a piece of data, like a number, and then after a 1000 milliseconds, it calls whatever callback I provided and just sends the data right back.

So I pretend to ask for the answer, the calculation of value 10. 1000 milliseconds later, the function is called and num1 is the value 10. Now x = 1 + 10. So x is 11. And then I make the call to 30. You notice that this is sequential calling.

I've nested these calls together because they have a temporal dependency, I can't calculate 31 until after I've calculated 11. And then after both of those have been calculated, then I put the two together, meaning of life 42. I ask for that from to be computed in 1000 milliseconds later I get my answer back.

Meaning of life 42.
>> Speaker 2: [INAUDIBLE]
>> Kyle: Yep sorry, we're talking about lines 5 and lines 7 for the getData calls. Line 9 for the getData call of meaning of life. And then finally the answer is coming back on line 11. Thankfully mine only took 1000 milliseconds or 3 instead of trillions of years or whatever.

That would be a pretty big number for the setTimeout. But you see here I have the nested callbacks. And I have all the problems of, this is non-local non-sequential reasoning even. Yes, vertically, I can move through the pyramid. But what happens when I move one of those callbacks into another module of my utility?

Now I've got this non-local jump over to some other location to understand what's happening. [COUGH] And I have all the trust issues in inversion of control.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now