[JavaScript] confused about async/await even after reading docs

Posted by NeedleworkerLumpy907@reddit | learnprogramming | View on Reddit | 7 comments

I’ve read MDN and a few blog posts about async/await, but I still don’t “feel” how it actually pauses code. I understand that it doesn’t block the whole program, but when I step through it mentally, I get lost. What I tried: * console.log before and after `await` * reading about promises first * searching “async await explained simply” What I don’t get is: Why does code *after* `await` sometimes run later, but variables still have the correct value? Not asking for full example app, just want to understand what’s happening in my head wrong.

Reply to Post

7 Comments

[-]

fixermark@reddit

In your computer is something called the "current runtime state." What that phrase means varies a little depending on what layer of abstraction you're talking about; if you're talking machine code, the state is * The current program counter (i.e. "What instruction am I actually working on") * All the registers (i.e. "What values am I currently adding / subtracting / etc") * The stack pointer (i.e. "Where am I in the big chain of functions I'm working on. In JavaScript, analogously, it's more-or-less what line you're on, what function you're in, the stack of functions called to get here, and all the local variables. I'm hand-waving a bit, but that's more-or-less correct. Once you have all that runtime state, the system (in this case, the JavaScript engine) can treat the work you're doing as an object and "put it on the shelf" as it were. An async function is allowed to be "suspended": under the hood, the return type of an async function is always "Promise(something)", not something. Call an async, get a Promise back; that's always true. A Promise is a fancy little object that has slots for the value that gets resolved (or rejected) but otherwise isn't too fancy. The await keyword takes in a Promise. If that Promise isn't resolved or rejected yet, it lets the system put the runtime state on the shelf, pick something else off the shelf, and do that instead. The shelf could be holding other async functions that were awaited, or it could be holding network calls that haven't responded. If there's nothing ready to resume on, your browser JavaScript runtime will at least keep checking for events like mouse and keyboard input. Note that it can also go to the shelf if it "runs out of things to run," i.e. all the handlers for mouse and keyboard input, etc., are all done. When a promise is resolved, the runtime state that was waiting on it gets picked up off the shelf and runs. The await turns Promise.resolve into a return value and Promise.reject into throwing an error. The most important thing to know is that this is not multithreading. There is only ever one executing current runtime state; the rest are on the shelf waiting to be executed when they get their turn. But computers are *fast* so it *feels* a lot like multiple things happening at once. Also, JavaScript won't ever just pause your program mid-statement; it can only suspend execution when await has to handle a Promise.

[-]

peterlinddk@reddit

>What I don’t get is: Why does code *after* `await` sometimes run later, but variables still have the correct value? Are you perhaps experiencing the "trick" that console.log plays on you, where you console.log an object, and then click to expand it, and the values it shows are the current values, and not the original values when the console.log line actually ran? It confuses the heck out of everyone - and a simple trick to get around it is to stringify the variable first, as in: console.log(JSON.stringify(variable)) - then you get the actual value at the time of logging, and not at the time of clicking.

[-]

ucladurkel@reddit

Take this analogy with a grain of salt because it's not super technically accurate, but think of an async function as an errand like doing your laundry. The "function" would be something like: 1) Load the washer and turn it on 2) Wait for the washer to finish 3) Move clothes to the dryer 4) Wait for the dryer to finish 5) Fold your clothes Step 3 can't be done until step 2 is done, and step 5 can't be done until step 4 is done. But that's a lot of waiting and you're a busy person! If you had an assistant, you could have them do the laundry while you work on something else. So your assistant loads the washer and then waits for it to finish before moving to the dryer etc. And all this time you're working on more important things. If you need your laundry done at some point but don't care about when, just have your assistant do all of the steps and they will finish whenever they finish. But, if you need clean clothes before your business meeting later, you can have your assistant do the laundry (i.e. calling the async function), you can do whatever you need to, and then _await_ the return of your clothes before you leave. Once again this analogy isn't really accurate for JS since it's single threaded (there's no assistant, just you efficiently swapping between tasks), but the idea I'm trying to get across is that the async function kind of just works on its own, waiting and keeping track of variables. If you're awaiting that function, you just chill out until it's done whenever that may be, and the variables will all be correct. Hope that made some semblance of sense

[-]

paperic@reddit

``` const y = 'something' promise.then( x => { doStuff(x, y) } ) ``` is the same as ``` const y = 'something' x = await promise doStuff(x) ``` In both cases, the variable y is accessible. In the first case it's accessible because it's captured in that x => .... closure, and in the second case, it's also because it's captured in a closure. That's because the v=await p is just a syntax sugar for p.then(v => ...) It is quite difficult to figure out what runs when when doing async stuff with just console log. Try a debugger, but it's still kinda hard. You can almost imagine as if the stuff running after the await was in setTimeout(..., bitOfTime). The pre-await code will run first, the function will return a promise on the "await", and the rest of the function is effectively not actually part of the same function. It looks like part of the same function, but everything after the await is effectively wrapped in a lambda. That lambda is simply scheduled to run a bit later, as if the code got triggered by some onclick event or something.

[-]