Async Generators Q&A

[00:00:00]
>> Will Sentance: But before we get to that, you lost me and it's okay. I'm clear, I have some clarification questions on this new model of execution. Everybody thumbs proudly out, it's okay to have. Alec has a clarification, Abdi has more than a clarification. Brian has a clarification, Brian do you wanna go first?

[00:00:20]
>> Brian: Yeah, so this is still asynchronous when you get down to the, then we're still adding everything to the micro task through before it.
>> Will Sentance: It is.
>> Brian: So it was like a console log after that that would go first.
>> Will Sentance: Absolutely. If I had, I should have done that.

[00:00:36]
If I had a console log straight after this storing the due when dates received on the then,
>> Will Sentance: On the future date on fulfillment array and a console.log straight after, what were to happen. If I were to block my thread here, after the assignment to the due when date received, the future.data's on fulfillment array.

[00:00:55]
If I were to have a blocking task there for while it was infinite, then my due when date to receive the triggers inside of it, entering back into createFlow. I'd never reach that, because that's on my micro task queue. So it's still absolutely asynchronous. All this is doing, you can almost think of the code console log, you can almost think of everything after the yield statement that threw out the tasks, that threw out the promise object feed data.

[00:01:23]
Think of everything like this as being like the functionality we want to run on the date coming back. Almost think of this as being the function we pass here, like think of it as being this here is our functionality run later. But now we get to go and run it, we get to write it as though it's synchronous code in a function.

[00:01:46]
We just come back to it only when we trigger coming back to, only when we trigger running due when date received. Which we then get to manually set, now I get to go back and run this code. It's the most control we've had probably over when our deferred functionality runs.

[00:02:04]
But in the end, it's still, as by the very nature of asynchronicity in the language, beyond our control, because what triggers returnNextElement.next running that takes us back in here, what triggers it? It's the beyond our control setting a value property that beyond our control triggered due when date received.

[00:02:24]
But now when we trigger that we just write inside a command that we did get to control writing that takes us back into this function. But the very nature of a single thread in asynchronous language is that you throw out tasks. In a single thread you throw them out, and then they come back in, and run functionality on the return values beyond your control.

[00:02:43]
That's their very nature, and that's why in the end, solution two, which was the call back model, in the end it's also true. It's not a wrong model. Under the hood it's the same thing. Under the hood, we're not doing profoundly more here. You just increasing readability more and more.

[00:03:01]
And in a sense by doing so, hiding the underlying engine more and more. And that's arguably a problem of you don't understand the underlying engine. If you do, now you get best of both worlds. Increased readability and the ability to understand how it's truly working.