However, in essentially all cases, "immediately" means in terms of the Job queue behavior (see Chapter 1), not in the strictly synchronous now sense. Note: The word "immediately" will be used frequently in this chapter, generally to refer to some Promise resolution action. So it's probably a good idea to dig in and learn them, don't you think!? In fact, most new async APIs being added to JS/DOM platform are being built on Promises. Promises are starting to take the JS world by storm, as developers and specification writers alike desperately seek to untangle the insanity of callback hell in their code/design.
WHAT YOU DONT KNOW JS CODE
We do this because we want to say, "here's what happens later, after the current step finishes."īut what if we could uninvert that inversion of control? What if instead of handing the continuation of our program to another party, we could expect it to return us a capability to know when its task finishes, and then our code could decide what to do next? Recall that we wrap up the continuation of our program in a callback function, and hand that callback over to another party (potentially even external code) and just cross our fingers that it will do the right thing with the invocation of the callback. The issue we want to address first is the inversion of control, the trust that is so fragilely held and so easily lost. Now that we understand the problems more intimately, it's time we turn our attention to patterns that can address them. In Chapter 2, we identified two major categories of deficiencies with using callbacks to express program asynchrony and manage concurrency: lack of sequentiality and lack of trustability. The call-site we care about is in the invocation before the currently executing function.You Don't Know JS Yet: Sync & Async - 2nd Edition Chapter 3: Promises NOTE:Įverything below here is previous text from 1st edition, and is only here for reference while 2nd edition work is underway. What's important is to think about the call-stack (the stack of functions that have been called to get us to the current moment in execution). We must inspect the call-site to answer the question: what's this this a reference to?įinding the call-site is generally: "go locate where a function is called from", but it's not always that easy, as certain coding patterns can obscure the true call-site. To understand this binding, we have to understand the call-site: the location in code where a function is called ( not where it's declared). In Chapter 1, we discarded various misconceptions about this and learned instead that this is a binding made for each function invocation, based entirely on its call-site (how the function is called).
You Don't Know JS Yet: Objects & Classes - 2nd Edition Chapter 2: this All Makes Sense Now! NOTE:Įverything below here is previous text from 1st edition, and is only here for reference while 2nd edition work is underway.
0 kommentar(er)
