Thunks and Closure

[00:00:00]
>> [MUSIC]

[00:00:03]
>> Kyle: Thought it'd be useful to just very quickly circle back to kind of talk about this notion of what a thunk really is. And actually it's not all of that, it's not really all that special, it's just maybe a usage of the callback pattern that we aren't terribly familiar with.

[00:00:21]
Most of us probably at least have some passing familiarity with closure. And that's really what the func is all about is using closure to maintain state, now why is that so important? So some questions on the chat before about what our thunks? Are they solving callback hell or things like that?

[00:00:42]
Well they're still callbacks so they're not fundamentally changing that particular game. Callbacks aren't really I mean thunks are not really adding anything to the equation in terms of better trustability. Or even I mean they're a little bit more reasonable I suppose this code is clearly a bit more reasonable than what we had before with just regular callbacks.

[00:01:05]
But it's not fundamentally more linear or sequential, or synchronous in nature. So really hasn't moved the ball much on that respect. So thanks really aren't specifically about solving callback hell. But they do solve a really important problem that sets us up for the rest of the stuff that we're going to discuss in this workshop.

[00:01:23]
And that's why, I chose to spend time pushing on them, it's not just a trivia sort of thing that they really are an important conceptual foundation upon which we build the rest of stuff. So the major thing the major takeaway, why is the thunk so important to me why should I care.

[00:01:40]
And why should it be something that's part of my arsenal of weapons that I used to take down asynchronous programming issues? Well the reason for that is, that by using the closure in the in the thunk pattern by using the closure to maintain the state of something. We eliminate time as a complecting factor of state.

[00:02:04]
Time is the most complex factor of state in your program. Understanding the order in which things happen and the way things change over time is the most complex part of your application. It's the hardest part for us to reason about, is it impossible? Clearly not but it does make it harder.

[00:02:23]
So if we can use this tool, this notion of preserving state inside of this value wrapper container that we call a thunk. We then are able to compose these values together, and not worry about the ordering, time becomes a non-issue. As you can see here with this code, I am sequencing the thunk one thunk two and thunk three together.

[00:02:48]
And we know already having looked at the previous solution, hopefully that's fresh enough in your minds. Having looked at this solution we see that there is basically a race condition if you will. Between whether we ask for the thunks response before it has it, or whether the response comes back before it's been asked.

[00:03:09]
There's a fundamental race condition there, that's a time issue. That's a complexity issue that we had to manage ourselves in the previous exercise by writing all that for loop crap and stuffing things inside of a global variable. That complexity is something that we had to solve ourselves this pattern solves that for us.

[00:03:29]
It takes a value and eliminates the time as the concern, it doesn't mean it eliminates all concerns but the most complex of our concerns is eliminated. It's not even really eliminated, it's just simply abstracted away. So it's not something we have to be concerned about in the parts of our code where we're consuming these issues, consuming these values.

[00:03:49]
So we write the plumbing once if you will, the mechanism by which a thunk is created as I showed you just there. And then where we use it, it's the lines 41 through 50 that represent the bulk of our code that we write over and over and over again.

[00:04:02]
We write code to reason about asynchronous actions that are occurring and this is the kind of code that is significantly more reasonable. Than it was before because we don't have to worry about time in this issue. That's what is so important and I'm harping on this so much because I think the next topic that we're about to talk about we're about to jump into promises.

[00:04:24]
And I think the point has largely been missed about why promises are so revolutionary. I think most people have focused on promises as an API and to be honest with you? The API for promises is the least interesting part to me. It's far more interesting to me that promises are a qualification of this pattern built in for us.

[00:04:49]
So that we don't even really have to think about it as much it's even there for us automatically. A qualification of this pattern of managing state internal inside of a wrapper in a time independent way. There is more to promises than that, but the that in and of itself is revolutionary.

[00:05:07]
That in and of itself is bringing to the masses something which we could have been doing all along. But for whatever reason this wasn't something that we spent time thinking about. I've written an awful lot of really bad asynchronous code and I wish I could go back and fix all of that stuff to have been using a pattern like songs.

[00:05:23]
Because this would have been a lot better than what I had before but it's not the end of the story. There's more to go, much more to go in this workshop. So with that as our foundation is a reminder of where we're at and why thunks are so important.

[00:05:35]
Let's dive in and talk about promises.