Say hello everyday.
Today we are going to complete the implementation before there are still some small methods not fulfilled Promise.
Review: Implementing a Promise library that complies with the PromiseA+ specification step by step (1)
Implement a Promise library step by step that complies with the PromiseA+ specification (2)
Resolve, Promise. Reject, Promise. Reject, Promise. All, Promise. Race.
Let’s implement the.catch method.
Let’s look at the following code
We are using es6 native Promise here and see the result of catch versus Reject. And we can see that in the then method there is only ondepressing one callback function.
Also, the catch method supports chained calls, so. We need to mount this method on our Promise.
So we implement the catch method in Promise, isn’t that easy?
As you can see from our previous tests, the parameters in the.catch method have only one callback function, and this callback function has one parameter. After all, the catch method always gets the value of our onRejected state. So we return a THEN method and only call the then method onRejected. The ondepressing state in the then method is passed with a null, why? This is a big pity and onFulfilled default value in (2) which is a Promise which conforms to the PromiseA+ specification step by step. We won’t go into it here.
Let’s take a look at promose. resolve and promise. reject.
The forehead.. These two methods return a Promise of success and a Promise of failure, respectively. These two methods hang directly on a Promise as static methods.
Next we implement the promise.all method.
We know that the promise. all method processes an array of promises and returns a Promise. When all promises are processed, the array of results will be returned the next time we call the then method. Let’s look at the code below.
Promise. All usage
So we can implement our promise.all method based on this principle.
Let’s look at the following code.
The forehead.. I think that’s pretty clear. Let me get this straight.
Take the Promise array -> iterate through it (call its then method)-> store it in the return array -> determine if the execution is complete (complete: return our array).
I’m running a little late today, so let’s just implement these. Race method tomorrow or sometime. Then we will share the asynchronous development process of javascript.
The original callback->Promise->generator function -> our now common async await
Sauce:)
update
Implementation of the RACE method.
Promise.race is an interesting method. This method takes an array of promises like the All method, but if one of these promises is successful, our race method completes and returns the result of the Promise’s execution. Let’s look at usage first.
We see that there is an array of promises in the race method, but only one result is returned. And the race method also returns a Promise, because we get the result of the previous execution in the subsequent THEN method. So. So let’s implement that.
As we can see, in the loop we call the Promise we passed in directly, and then call the resolve method of the Promise we returned to return the result of the execution when it succeeds.
At this point, we’ve basically implemented a fairly complete Promise, which is of course relatively simple. But we’re doing pretty well.
Let’s take a look at the asynchronous development flow of JS.
We all know that we used to have code like this when we were dealing with asynchrony for example.
The callback function
If {
I mean {
Can you {
Do one thing {
}
}
}
}
The ugly ones.
. It’s not bad, but mostly pretty. But if we do too much asynchronously, callback hell is inevitable. So Promise came into being.
Let’s take a look at Promise
The usual code looks like this
Promise.resolve().then().then()……
“Then” is not a good look. And two callbacks in a THEN, which returns a Promise. EMMMMM..
Then comes our generator function.
generator
Those of you who have used generator functions should know. Generator can return multiple times during execution, so it looks like a function that can remember the execution state. Generator functions are usually used in conjunction with co libraries written by Promise and TJ. Since the generator function generates an executor, we use the next method of the executor to execute our asynchronous method to get the desired value.
If you don’t understand how generator works, take a look at how it works. -> The meaning and usage of Generator functions
The CO library helps us ignore the next method in the executor, return a Promise and put the result of the execution into the then method of the returned Promise.
We can implement a CO library by ourselves, which is actually a very simple method.
Let’s take a look at the test results
The discovery is still no problem. Thus we have written a simple CO library to help us use generator functions.
The last one is our async and await.
async-await
We can see that async and await are used in the same way as generator functions. Async and await are syntactic sugars of generator and yield.
Of course, the implementation of this syntax sugar is a bit complicated, and we will implement it with you if we have time. Let’s take a look at his usage here.
As we can see, async returns a Promise as well and automatically executes the next method in the Generator, freeing us from having to deal with the executor and making our development experience much better during development. After all, it’s better to keep the code clean…
Well, along the way we also have A relatively complete understanding of the Promise implementation principle, we can also be considered to complete A Promise library in line with the Promise/A+ specification. Then we also understand the asynchronous development of JS in recent years, do you feel great? (I think we’re pretty good anyway)
Finally, I hope everyone can be better in life, study and work. Thank you again for being there. Thank you.
Sauce, Bye ~
