Promises & Async Await Concept Understanding
I'm reviewing async await rn, and I just wanted to clarify something RE Promises.
Promises, on their own, are NOT asynchronous... correct? We use async await with promises in order to make them asynchronous?
5 Replies
A Promise is not really asynchronous, but it represents an asynchronous operation. In other words, there's no point in using Promise without an asynchronous operation associated to it, therefore is not unreasonable to think of Promises as asynchronous themselves.
However,
async and await are keywords that make working with promises easier. It's what's called syntactic sugar which means it's a simpler/nicer way of writing equivalent code. In this case they are meant to handle the resolve and reject cases of a promise easier.
So, no, we don't use async and await to make anything asynchronous. We use them to make the code we write simpler to reason about.
With that in mind, one way of thinking about it is with async, you are "forcing" a function's return value to be a Promise. With await you are forcing the main thread of execution to, well, wait until this function returns in order to proceed with the code at that point.
However, this "wait" is actually different than the main thread waitinf for a function to return. The main difference is that the thread of execution knows this function may take some time as it is returning a Promise, and can jump to address other areas of the code that need to be executed eg. timeouts, intervals, user input, browser events, etc.I wanna jump on this one, since this is what I'm going through right at the moment, and @joao6246, it kind of goes back to my question about classes and constructor functions ...
The codecademy course specifies a promise as:
"An asynchronous operation is one that allows the computer to “move on” to other tasks while waiting for the asynchronous operation to complete."
So what makes promises asynch is basically that you have the resolve and reject parameters?
The next step is the
.then() function to run when the promise has been settled. Is this correct?I think it's best to keep things simple, really, there's no need to overthink it too much.
A Promise is just an object, the only thing special about it is that it has different states ie: pending, resolved, etc. You interact with this object using its
then and catch methods to run some code conditionally, based on whether the promise has moved on to one of the resolved or rejected states. The idea is that JavaScript will keep track of it and run the code you provided when the state of the promise has changed.
The idea of async and await is to abstract the logic of working with then and catch and make the code look a little more "synchronous" which is how we're normally used to think about code. But we gain the ability to have different tasks running at the same time i.e., not blocking the thread of execution.
The next step is the .then() function to run when the promise has been settled. Is this correct?This is the most important part to understand. Just know that when you have a function that returns a promise, you have to use
then to tell it what happens when the promise resolves (and catch to handle errors).
Technically though, you don't have to use then if you don't want to. It's just the mechanism that will ensure that code runs after the promise is resolved. It's rare, since you normally want to at least log the result, but it's perfectly valid.I think one of the issues with learning through courses is that they touch down on all aspects of all code. I'm imagining that when we get to React, Next, and all these kinds of tools, we probably won't use half of everything codecademy mention in their course.
Which is why I asked for the button example earlier today ...
Yes, it's sometimes too much. The best way to understand and learn is by making something. Classes and Promises are basic but until you use them in some project and run into errors, etc, you won't really understand where each piece goes, or why it behaves the way it does.
But it's good you learn all of this before you move to React or any other framework, that's a classic mistake