JavaScript Promise Mini-Book (Chinese version)

 promise =  Promise(function(resolve){
    resolve();
});
promise.then(function(value){
    console.log(value);
}).catch(function(error){
    console.error(error);
});Copy the code

----
getAsync(fileA.txt, function(error, result){(1)(error){// Throw error; } // Handle success}); ---- <> (error )Copy the code

Promise
----
 promise = getAsyncPromise(fileA.txt); (1)Then (function(result){catch(function(error){// fetch file (error)}); ---- <> promiseCopy the code

Promise = promise (function(resolve, reject) {// call resolve or reject});Copy the code

promise.then(onFulfilled, onRejected)Copy the code

promise.catch(onRejected)Copy the code

Let’s take a look at the following example code.

AsyncFunction returns a Promise object, for which we call the then method to set the resolve callback and the catch method to set the error callback.

The promise object will be resolved 16ms after setTimeout, when the then callback will be called and output ‘Async Hello World ‘.

The catch callback will not be executed in this case (because promise returns resolve), but if the runtime environment does not provide a setTimeout function, the above code will raise an exception and the callback set in the catch will be executed.

Of course, like the promise. Then (onFulfilled, onRejected) method declaration, the code shown below can do the same if you use only the THEN method without the catch method.

Now that we have an overview of how promises work, let’s sort out the Promise states a little bit.

A Promise object instantiated with New Promise has three states.

“has-resolution” – Fulfilled

Resolve. Ondepressing will be called at this time

“has-rejection” – Rejected

Reject (reject) OnRejected is called

“unresolved” – Pending

It is neither resolve nor Reject. That’s the initial state of the promise object after it’s created

Promises/A+ : Promises/A+ : Promises/A+ : Promises/A+ : Promises/A+ : Promises/A+ : Promises/A+ : Promises/ B

Basically, the state is not covered in the code, so the name doesn’t matter too much. In this book, we will talk about Pending, depressing and Rejected states in Promises/A+[8].

So far in this article we’ve covered all three states of promise.

After the state of the Promise object is changed from Pending to Fulfilled or Rejected, the state of the Promise object will not change again.

That is, unlike, say, events, functions that are executed after. Then can be said with certainty to be called only once.

In addition, either of the states of depressing and Rejected can be represented as Settled.

Settled

Resolve or reject.

From the symmetry between Pending and Settled, the type/migration of Promise states is very straightforward.

Use.then to define functions that will be called only once when the state of the promise object changes.

The process for creating a Promise object is shown below.

1. New Promise(fn) returns a Promise object

2. Specify asynchronous etc processing in FN

   • If the result is normal, call resolve(process result value)

   • Call reject(Error object) if the result is incorrect

Let’s follow this process and actually write the Promise code.

Our task is to use Promise to retrieve XMLHttpRequest(XHR) data via asynchronous processing.

Create the XHR Promise object

function getURL(URL) { return Promise(function (resolve, reject) { req = XMLHttpRequest(); req.open(, URL, ); req.onload = function () { (req.status === ) { resolve(req.responseText); } { reject( Error(req.statusText)); }}; req.onerror = function () { reject( Error(req.statusText)); }; req.send(); }); } // Run the sample URL = http://httpbin.org/get; getURL(URL).then(function onFulfilled(value){ console.log(value); }).catch(function onRejected(error){ console.error(error); });Copy the code

Let’s use the function we just created that returns a Promise object in action

As outlined in Promises Overview, the Promise object has several instance methods that we use to create callback functions for the Promise object that depend on the specific state of the promise and will be executed only once.

There are two main ways to add processing to a Promise object

• Ondepressing when the promise object is resolved

• A promise object is rejected (onRejected)

First, let’s try the handler that is added when getURL communicates successfully and fetches a value.

At this time, the so-called successful communication means that after the promise object is resolved, it will become a pity state.

If resolve is resolved, the desired function can be passed in the. Then method.

Resolve (req.responsetext) in getURL; The promise object will change to the resolve (depressing) state, and the ondepressing function will be called with its value.

So far we haven’t done anything to deal with any errors that might occur, so let’s add exception handling to the getURL function in case of an error.

The reject state is Rejected, and the promise object changes to Rejected.

Reject, either in the second argument to.then or in the.catch method, which sets the desired function to be called.

Add the reject to the previous code, as shown below.

When any exception occurs in getURL processing, or is explicitly rejected, the cause of the exception (the Error object) is called as an argument to the.catch method.

Catch is just an alias for promise.then(undefined, onRejected).

In general, it is recommended to write resolve and reject separately using.catch, which is explained in more detail in then and catch.

The static promise.resolve (value) method can be thought of as a shortcut to the new Promise() method.

Such as Promise. Resolve (42); Think of it as syntactic sugar for the following code.

Resolve (42) in this code; This will immediately put the Promise object into the resolved state and pass 42 to the onFulfilled function specified in the later THEN.

Method Promise. Resolve (value); The return value of is also a Promise object, so we can follow up with a.then call to its return value as follows.

Promise.resolve is a shortcut to new Promise(), which is handy when initializing a Promise object or writing test code.

The Promise. Resolve method also serves to convert the Thenable object into a Promise object.

ES6 Promises Promises about Thenable. In a nutshell, it is a very similar promise.

Just as we sometimes call a non-array object with a.length method Array like, thenable refers to an object with a.then method.

This mechanism for converting Thenable into Promise requires that the THEN methods owned by Thenable should have the same functions and processing as the THEN methods owned by Promise. When converting Thenable into Promise, It also makes clever use of the thenable object’s original THEN methods.

The simplest example of a thenable object is jquery.ajax ()[10], which returns thenable.

Because the return value of jquery.ajax () is a jqXHR Object, this Object has.then methods.

This Thenable object can be converted to a Promise object using promise.resolve.

Promises are Promises that allow you to use “then” or “catch” — methods defined in ES6 Promises.

Promise. Resolve uses only the common method then, providing the ability to convert Promise objects between different libraries.

This conversion to Thenable was previously done using promise.cast, and it’s not hard to imagine what it could do from its name.

Aside from the need to know something about Thenable when writing software such as libraries that use Promise, we probably don’t use this feature when we’re typically using it as end-user.

The Promise. Resolve method will fulfill the parameters passed to it and return the Promise object.

In addition, many Promise processing uses the Promise.resolve algorithm to convert a value to a Promise object before processing it.

 Promise(function(resolve,reject){
    reject( Error());
});Copy the code

Promise.reject( Error(BOOM!) ).catch(function(error){ console.error(error); });Copy the code

 promise =  Promise(function (resolve){
    console.log(inner promise); 
    resolve();
});
promise.then(function(value){
    console.log(value); 
});
console.log(outer promise); Copy the code

inner promise // 1
outer promise // 2
42            // 3

This problem also exists outside of promises, and we’ll consider it in general usage.

The essence of the problem is that the function receiving the callback can choose whether to call the callback synchronously or asynchronously, depending on its execution.

Let’s take onReady(fn) as an example, which receives a callback function for processing.

Mixed-onready. js determines whether to call the callback synchronously or asynchronously based on whether the DOM has been loaded at execution time.

If the DOM is already loaded before onReady is called

Make synchronous calls to the callback function

If the DOM has not been loaded before onReady is called

Make asynchronous calls to the callback function by registering the DOMContentLoaded event listener

Therefore, if this code appears differently in the source file, the order of the log messages printed on the console will be different.

To solve this problem, we can choose to use asynchronous invocation uniformly.

This problem is also covered in Effective JavaScript[12], item 67, do not make synchronous calls to asynchronous callback functions.

• Synchronous calls to asynchronous callback functions, even when the data is ready, should never be made.

• If asynchronous callback functions are called synchronously, the processing order may not be as expected, possibly with unintended consequences.

• Synchronous calls to asynchronous callback functions can also lead to stack overflow or exception handling errors.

• If you want to call an asynchronous callback at some point in the future, you can use an asynchronous API like setTimeout.

Then also falls into this category. In order to avoid the confusion caused by simultaneous synchronous and asynchronous invocations mentioned above, the promise specification specifies that promises can only use asynchronous invocations.

Finally, if you rewrite the onReady function above with Promise, the code looks like this.

Since Promise guarantees that each call will be asynchronous, we don’t need to call setTimeout to implement the asynchronous call ourselves in the actual code.

aPromise.then(function taskA(value){
// task A
}).then(function taskB(vaue){
// task B
}).catch(function onRejected(error){
    console.log(error);
});Copy the code

In chapter 1, we see a simple example of then → catch in the Promise chain. If we make the method chain longer, how will the onFulfilled and onRejected registered in each promise object be implemented?

Let’s take a look at the following promise chain.

The execution flow of the Promise chain in the code above, if depicted in a diagram, would look like this.

In the code above, we do not specify a second parameter (onRejected) to the then method, which can also be understood as follows.

then

Register the callback function during Ondepressing

catch

The callback function when onRejected is registered

Task A and Task B have A line pointing to onRejected.

These lines mean that in the process of Task A or Task B, the onRejected method is called in the following case.

• When an exception occurs

• Returns a Promise object in the Rejected state

As we saw in Chapter 1, the processing in promises is conventionally try-catch style, and when an exception occurs, it is caught by a catch and error-handled by a callback registered in that function.

Another exception-handling strategy is to return a Promise object with the Rejected state. This method calls onRejected in the Promise chain without using a throw.

I won’t discuss this method in detail because it’s not relevant in this section, but refer to Using Reject rather than Throw in Chapter 4.

In addition, in the Promise chain, there is no catch after the onRejected and Final Task, so any exception in these two tasks will not be caught. This should be noted.

Task A → onRejected = Task A → onRejected

Example of an exception generated by Task A

Figure 4. Schematic diagram when Task A generates an exception

function taskA() { console.log(Task A); throw Error(throw Error @ Task A) } function taskB() { console.log(Task B); } function onRejected(error) {console.log(error);} function onRejected(error) {console.log(error); // => "throw Error @ Task A" } function finalTask() { console.log(Final Task); } promise = Promise.resolve(); promise .then(taskA) .then(taskB) .catch(onRejected) .then(finalTask);Copy the code

The tasks in the previous examples are independent of each other and are simply called.

What if Task A wants to pass A parameter to Task B?

The answer is simple: the value returned by the return in Task A is passed to Task B when it executes.

Let’s start with a concrete example.

The entry function for this code is promise.resolve (1); , the overall promise chain execution process is shown as follows.

1. Promise.resolve(1); Pass 1 to increment

2. Increment increments the received argument by +1 and returns (via return)

3. The argument becomes 2 and is passed again to the doubleUp function

4. Finally, the result is printed in function output

The return value in each method is not limited to a string or numeric type, but can also be an object or a promise object.

Resolve (the return value of return); Wrap accordingly, so that no matter what value is returned in the callback function, the result of the final THEN is a newly created Promise object.

That is, Promise#then does more than just register a callback function, it transforms the return value of the callback function to create and return a Promise object.

^[13]

^[14]

The figure above is the result of the following code being executed on a browser using Polyfill [15].

If we execute this code in various browsers, the identifier Not found syntax error will appear in IE8 and below.

What’s going on here? It actually has something to do with catch being an ECMAScript Reserved Word.

In ECMAScript 3 reserved words cannot be used as object property names. IE8 and below are implemented in ECMAScript 3, so you can’t use catch as an attribute, which means you can’t write code like promise.catch(), and hence the syntax error identifier Not found.

Today’s browsers are based on ECMAScript 5, and in ECMAScript 5 reserved words are identifierNames, which can also be used as property names.

Of course, there are ways to get around the ECMAScript 3 reserved words.

Dot notation requires that the attributes of the object be valid identifiers (reserved words cannot be used in ECMAScript 3),

But using bracket notation, you can use an invalid identifier as an attribute name for an object.

That is, the above code, if rewritten as follows, should run in IE8 and below (polyfill, of course).

Or we can avoid this problem by using then instead of just catch.

Because the catch identifier can cause problems, some libraries also use caught for the function name, which does the same job.

And many compression tools come with the ability to convert promise.catch to a promise[“catch”], so they may inadvertently help us solve this problem too.

Keep this catch issue in mind if you need a browser that supports IE8 or below.

aPromise = Promise(function (resolve) { resolve(); }); thenPromise = aPromise.then(function (value) { console.log(value); }); catchPromise = thenPromise.catch(function (error) { console.error(error); }); console.log(aPromise ! == thenPromise); // => true console.log(thenPromise ! == catchPromise); // => trueCopy the code

APromise = promise (function (resolve) {resolve(); }); aPromise.then(function (value) { return value * ; }); aPromise.then(function (value) { return value * ; }); aPromise.then(function (value) { console.log( + value); BPromise = promise (function (resolve) {resolve(); }); bPromise.then(function (value) { return value * ; }).then(function (value) { return value * ; }).then(function (value) { console.log( + value); // => 100 * 2 * 2});Copy the code

function badAsyncCall() { promise = Promise.resolve(); Promise.then (function() {return newVar; }); return promise; }Copy the code

function anAsyncCall() { promise = Promise.resolve(); Return promise.then(function() {return newVar; }); }Copy the code

This callback style code has the following points.

• Using the json. parse function directly might throw an exception, so a wrapper function, jsonParse, is used

• The hierarchy is deeper if multiple XHR processes are nested, so the allRequest function is used and request is called from there.

• The callback function is written as callback(error,value), with the first parameter representing the error message and the second parameter representing the return value

Using the jsonParse Function we used bind to reduce the need for anonymous functions by using Partial functions. (The number of anonymous functions can also be reduced if the separation of functions can be achieved in call-back style code.)

In this callback style code, we can also see the following problems.

• Need to display for exception handling

• To keep the nesting level from getting too deep, you need a function that handles the request

• Callbacks are everywhere

Let’s take a look at using Promise#then to do the same thing.

It should be noted that promise.all fits the needs of this application scenario, so we deliberately use a lot of. Then arcane notation.

If.then is used, it does not correspond to the style of the callback.

Comparing the above code to the callback function style, we can conclude the following.

• You can use the json.parse function directly

• The function main() returns a promise object

• Error handling takes place directly on the returned Promise object

As we said earlier, the then part of Main is a bit opaque.

To deal with this scenario where multiple asynchronous calls need to be handled uniformly, Promise prepares static methods promise. all and promise.race.

We will explain these two functions in the following sections.

function getURL(URL) { return Promise(function (resolve, reject) { req = XMLHttpRequest(); req.open(, URL, ); req.onload = function () { (req.status === ) { resolve(req.responseText); } { reject( Error(req.statusText)); }}; req.onerror = function () { reject( Error(req.statusText)); }; req.send(); }); } request = { comment: function getComment() { return getURL(http://azu.github.io/promises-book/json/comment.json).then(JSON.parse); }, people: function getPeople() { return getURL(http://azu.github.io/promises-book/json/people.json).then(JSON.parse); }}; function () { return Promise.all([request.comment(), request.people()]); } // Run the example main().then(function (value) {console.log(value); }).catch(function(error){ console.log(error); });Copy the code

Promise.all([request.comment(), request.people()]);Copy the code

main().then(function (results) { console.log(results); });Copy the code

Resolve function timerPromisefy(delay) {return Promise(function (resolve) {setTimeout(function ()) { resolve(delay); }, delay); }); } startDate = Date.now(); All ([timerPromisefy(), timerPromisefy(), timerPromisefy(), timerPromisefy()), timerPromisefy() ]).then(function (values) { console.log(Date.now() - startDate + ); / / about 128 ms console. The log (values); / /,32,64,128 [1]});Copy the code

 promises = [
    timerPromisefy(),
    timerPromisefy(),
    timerPromisefy(),
    timerPromisefy()
];Copy the code

Resolve function timerPromisefy(delay) {return Promise(function (resolve) {setTimeout(function ()) { resolve(delay); }, delay); }); } // The application stops running promise.race ([timerPromisefy(), timerPromisefy(), timerPromisefy(), timerPromisefy(), timerPromisefy() ]).then(function (value) { console.log(value); / / = > 1});Copy the code

winnerPromise = Promise(function (resolve) { setTimeout(function () { console.log(this is winner); resolve(this is winner); }); }); loserPromise = Promise(function (resolve) { setTimeout(function () { console.log(this is loser); resolve(this is loser); }); }); Race ([winnerPromise, loserPromise]). Then (function (value) {console.log(value); // => 'this is winner' });Copy the code

Let’s look at the code below.

In the above code, badMain is a bad implementation (but not that bad), and goodMain is a very good error-handling version.

Why is badMain bad? Because although we specify the error handling function in the second parameter of.then, it can’t actually catch the errors that occur in the function (throwError in this case) specified by the first parameter ondepressing.

That is, even if throwError throws an exception, the onRejected function will not be called (i.e., it will not print “BAD”).

In contrast, goodMain’s code follows the throwError→onRejected call process. An exception in throwError will be caught by the next method in the chain,.catch, and handled accordingly.

The callback function specified by the onFulfilled parameter in the. Then method is actually for its Promise object or the previous promise object, rather than the first parameter specified in the. Then method, which is the object that onFulfilled refers to. This is why then and catch behave differently.

In this case, then is the processing of promise.resolve (42). An exception occurs in onFulfilled, and the onRejected specified in the same THEN method cannot catch the exception.

Exceptions that occur in this THEN can only be caught by the catch method that appears after the method chain.

Of course, since the.catch method is an alias for.then, we can do the same with.then. It’s just that using.catch is more intentional and easier to understand.

Here’s what we learned.

1. This is a big pity. Use promise. Then (onFulfilled, onRejected)

   • This is a big onpity, which may happen unexpectedly in the onRejected.

2. This is a big pity. Then (onFulfilled). Catch (onRejected)

   • Exceptions generated in then can be caught in.catch

3. There is no essential difference between.then and.catch

   • Use it on separate occasions.

It is important to note that if the code looks like badMain, it is possible that the program will not behave as expected and therefore will not handle errors correctly.

Mocha is a testing framework tool under Node.js, and we won’t go into the details of Mocha[20] itself here. Readers interested in Mocha[21] can learn for themselves.

Mocha is free to choose any style from BDD, TDD, exports, and the Assert method used in the tests can also be combined with any other library. That is, Mocha itself only provides the framework for performing tests, leaving the rest up to the user to choose.

We chose to use Mocha here for three main reasons.

• It is a well-known testing framework

• Support for Node.js and browser-based tests

• Support for “Promise testing”

Finally, as to why we support “Promise testing, “we’ll talk about that later.

To use Mocha in this chapter, we need to install Mocha through NPM.

In addition, we use node.js’s built-in Assert module, so no additional installation is required.

First, let’s try writing code that tests a traditional callback-style asynchronous function.

If you want to test an asynchronous processing using the callback function style, the code with Mocha looks like this.

Save this code as basic-test.js, and you can test it using the command-line tools of Mocha you just installed.

Mocha’s IT method specifies the done argument, which waits until the done() function is executed so that asynchronous processing can be tested.

Asynchronous tests in Mocha will follow these steps.

This is also a very common implementation.

Next, let’s look at how to use done for the Promise test.

Promise. Resolve is used to return the Promise object, which will be FulFilled. Finally, the callback function set through.then is also called.

Columns like: Can promises only operate asynchronously? As already mentioned, promise objects are always called asynchronously, so tests need to be written as asynchronous calls as well.

However, in the previous test code, the problem occurred when assert failed.

In this test assert failed, so you might think you should throw a “test failed” error, when in fact the test doesn’t end until the timeout.

Typically, when an assert fails, it throws an error that the testing framework catches to determine the test failure.

However, in the case of a Promise, any errors that occur during the execution of the.then bound function will be caught by the Promise, and the testing framework will be unaware of the error.

Let’s improve the assert failed promise test so that it handles the test results when an Assert fails.

In the example above where the test failed properly, we added.then(done, done) at the end to make sure done is always called; Statements.

Done () is called when an Assert test passes (on success) and done(error) is called when an Assert test fails.

Thus, we wrote the same Promise test as the callback function-style test.

However, to handle assert failures, we need to add.then(done, done); The code. This requires us to be very careful when writing the Promise test, because if we forget to include the above statement, we could end up writing test code that never returns until the timeout.

In the next section, let’s take a look at what mechanisms support the “Promises test “in the original justification for using Mocha.

 assert = require(power-assert);
describe(Promise Test, function () {
    it(should return a promise object, function () {
         promise = Promise.resolve();
        return promise.then(function (value) {
            assert(value === );
        });
    });
});Copy the code

it(should be fail, function () { return Promise.resolve().then(function () { assert(false); // => Test failed}); });Copy the code

Since Mocha provided tests for promises, we thought it would be better to write according to Mocha’s rules. But this code can lead to unexpected exceptions.

Example: the test code for the mayBeRejected() function below, which returns a promise object that becomes Rejected when they are accepted.

The purpose of this test includes the following two points:

mayBeRejected()The return promise object becomes a FulFilled state

The test will fail

mayBeRejected()Return a Promise object with the Rejected state

Check the Error object in Assert

The above test code will call the function registered in onRejected when the promise object changes to Rejected, thus not fulfilling the promise processing flow and the test will succeed.

The problem with this test code is that the test will be consistently successful when mayBeRejected() returns a promise object that is a depressing state.

In this case, since the onRejected function registered in catch is not called, assert will not be executed and the test will always pass (passed, success).

To solve this problem, we can add a.then call before a.catch, which means that if a.then is called, the test needs to fail.

But then or catch? Exceptions thrown by failTest are caught by a catch.

The execution flow of the program is then → catch, and the Error object passed to the catch is of type AssertionError, which is not what we want.

That is to say, we hope the test can only pass the Promise object whose state will change to onRejected. If the promise object is onFulfilled, then the test will always pass.

When writing an example of testing against Error objects, how do you weed out cases where the test will pass by accident?

The easiest way to do this is to determine in your test code what to do in the states of various Promise objects.

This will become a depressing state

Tests are expected to fail

The Rejected state

Test with Assert

That is, we need to explicitly specify in the test code what processing needs to happen in the Fulfilled and Rejected states.

This way, you can write the test code that fails when the promise becomes a big pity.

Then in the or catch? We have already said that, in order to avoid missing the error processing, we recommend using then → catch instead of using the call form with two parameters like. Then (ondepressing, onRejected).

But When it came time to write the test code, Promise’s powerful error-handling mechanism was a hinderance. So we use. Then (failTest, onRejected), which specifies exactly what the promise should do in each state.

In this section, we’ve covered some of the unexpected things that can happen when you use Mocha for Promise testing.

• Normal code is easier to understand if it follows the then → catch process

  • This is for error handling convenience. See then or Catch?

• Centralize the test code to then for processing

  • To be able to pass the AssertionError object to the test framework.

By writing. Then (onFulfilled, onRejected), we can explicitly specify what to do when the promise object becomes Fulfilled or Rejected.

However, code like the one below always looks a bit less intuitive due to the test processing of Rejected when you need to display it.

In the next section, we’ll show you how to write helper functions to make it easier to write Promise tests, and how to write tests that are easier to understand.

Promise. then(failTest, function(error){// Use assert to verify the error object assert(error instanceof error); });Copy the code

To write effective test code, we need to explicitly specify the state of the promise as either Depressing or Rejected.

But because.then can be called without parameters, it is sometimes possible to forget to add conditions that make the test fail.

Therefore, we can define a helper function that explicitly defines the expected state of a promise.

First we create a shouldRejected Helper function named for the example where they expect the test to return an onRejected status in the.then example.

The shouldRejected function accepts a promise object as an argument and returns an object with the catch method.

You can use the same code in the Catch as in onRejected, so you can use the assertion method in the catch.

Outside shouldRejected, these are codes similar to the following and treated much the same as normal promise.

1. Pass the promise object to be tested to the shouldRejected method

2. Write code that handles onRejected in the catch method of the returned object

3. Assertion in onRejected

When shouldRejected function is used, if the depressing is called, an exception will be thrown and the test will fail.

The test code will also be intuitive using a shouldRejected helper function like this.

As above, we can also write a shouldFulfilled helper function that tests the promise object and expects the result to be Fulfilled.

This is essentially the same construction as shouldRejected-test.js above, except that the catch method returning the object is then, promise.then the two arguments are switched.

In this section, you learned how to write test code for Promise specific states and how to use testable helper functions.

In addition, the helper methods in this section all presuppose Mocha’s support for Promises, which can be cumbersome to use in done-based testing.

It’s up to everyone to choose between using the Promis support based on the testing framework or using a callback style like Done. It’s just a matter of style, and I don’t think it’s necessary to argue over which is better.

For example, when testing under CoffeeScript[25], it might be easier to understand done because CoffeeScript implicitly uses return.

Testing promises is more difficult than testing asynchronous functions in general, and while it’s up to you to decide which way to test, it’s important to test consistently within the same project.

Why do you need these libraries? I’m sure some readers have this question. The first reason that comes to mind is that some runtime environments do not support ES6 Promises.

One of the first things to consider when looking for Promises on the Web was Promises/A+ compatibility.

Promises/A+ is the predecessor of ES6 Promises, and Promises’ THEN also comes from this community-based specification.

Promises/A+ : Promises/A+ : Promises/A+ : Promises/A+ : Promises/A+ : Promises/A+ : Promises/A+ : Promises/A+ : Promises/A+ : Promises/A+

Promises/A+ is really just A specification for Promise#then, so some libraries might implement other things like All or Catch with A different name.

If we say that a library is then compatible, we actually mean Thenable, which transforms Promise objects based on ES6 promises by using promise.resolve.

In these Promise implementation libraries, we focus on two types of libraries here.

One is called Polyfill, and the other is Promises/A+ compatibility, but adds its own unique features.

Polyfill

Promise extends the class library

This section introduces Polyfill and extension libraries in Promise’s implementation library.

Promise’s implementation libraries are numerous, and it’s up to you to choose which one to use.

However, because these libraries implement Promises that have Promises/A+ or ES6 Promises common interfaces, you can sometimes refer to code or extensions from other libraries when using one of these libraries.

One of the goals of this book is to become familiar with the common concepts in Promise and to become comfortable with these technologies in practice.

Here we use the desktop notification API Web Notifications[38] as an example.

Detailed information about the Web Notifications API can be found at the Web site below.

Simply put, the Web Notifications API displays Notification messages via new Notification as shown in the following code.

Of course, in order to display Notification messages, we need to get permission from the user before running new Notification.

The result of the user selecting the allow Notification dialog is passed to our application through notification. permission, which can be either granted or denied.

In the program can pass Notification. RequestPermission () to pop up whether to allow Notification dialog box, the result of the user to select the status parameter to the callback function.

We can also see from this callback that the user’s choice to allow or deny notifications is asynchronous.

The process is as follows until the user receives and displays the notification.

• Displays a dialog box to allow notification and asynchronously processes the result of the user’s selection

• If the user allows it, the Notification message is displayed through new Notification. There are two cases

  • The user has allowed this before

  • A dialog box is displayed asking you whether to allow desktop notification

• If the user does not allow the operation, no operation is performed

Although there are several scenarios mentioned above, the end result is user approval or rejection, which can be summarized in the following two modes.

Allow (” granted “)

Use new Notification to create Notification messages

Rejection (” denied “)

There is no operation

Do you feel like you’ve seen these two modes before? Ha ha, the user’s choice result is very similar to the Promise object which becomes a pity or Rejected state in the Promise.

Resolve (successful) == user permission (“granted”)

Call the ondepressing method

Reject == User reject(“denied”)

Call the onRejected function

Can we code desktop notifications as promises? Let’s start with callback-style code to see how it works.

First, let’s rewrite the Web Notification API wrapper function above with back to function style code, as shown below.

In callback-style code, error is set when the user refuses to receive a notification, and notification is displayed and set if the user agrees to receive a notification.

Next, I want to rewrite this callback function style code again using Promise.

Based on the above callback style notifyMessage function, let’s create a notifyMessageAsPromise method that returns a Promise object.

When the user is allowed to receive notifications, running the code above will display “Hi!” The message.

The.then function is called when the user receives a notification message, and the.catch method is called when the user rejects the message.

The above notification-as-promise.js may seem convenient, but it may not work in an environment that does not support promises.

If you want to write a promise-style library like notification-as-Promise.js, I think you have some options.

The environment that supports Promise is the premise

• End users are required to guarantee support for promises

• Does not work (that is, should fail) in an environment that does not support promises.

Implemented in the class library
Promise

• Implement the Promise functionality in the class library

• For example) localForage [39]

It should also be available in callback functions
Promise

• Users can choose the appropriate way to use it

• Return type Thenable

Notification-as-promise. js is written on the premise that a promise exists.

Back to the body, Thenable is here to help implement the concept of using Promise in callback functions as well.

We’ve already said that thenable is an object with a.then method. Let’s add a method to notification-callback.js that returns type thenable.

NotifyMessageAsThenable has been added to notification-thenable.js. This method returns an object that has a THEN method.

The then method takes the same arguments as new Promise(function (resolve, reject){}), which executes resolve when it is certain and calls reject when it is rejected.

The then method does the same thing as the notifyMessageAsPromise method in notification-as-Promise.js.

Resolve (thenable) We can use the Promise feature by using the Thenable Promise object.

• The class library side does not provide an implementation of Promise

  • The user implements the Promise themselves via promise.resolve (thenable)

• Resolve (thenable) is used in conjunction with promise.resolve (thenable)

By using Thenable objects, we can implement an implementation style similar to the existing callback style and Promise style.

In this section we learned what Thenable is and how to use Thenable as a Promise object through promise.resolve (Thenable).

Callback — Thenable — Promise

The Thenable style appears to be somewhere between the callback and the Promise style, and as a public API for class libraries is a bit immature, so it’s not very common.

Thenable itself does not rely on the Promise feature, but there is no way to use Thenable outside of Promise, so Thenable can be considered to be indirectly dependent on Promise.

In addition, users need to have an understanding of promise.resolve (thenable) to use Thenable well, so part of the public API as a class library can be difficult. Thenable is used internally more often than in public apis.

When should YOU use Thenable?

Q = require(); Promise = promise (function(resolve){resolve(); }); Then (function(value){console.log(value); }).finally(function(){(1)
    console.log(finally);
});Copy the code

promise = Promise(function(resolve, reject){ throw Error(message); }); promise.catch(function(error){ console.error(error); // => "message" });Copy the code

promise = Promise(function(resolve, reject){ reject( Error(message)); }); promise.catch(function(error){ console.error(error); // => "message" })Copy the code

Then again, why should YOU use reject instead of throw when you want to set the state of a Promise object to Rejected?

First of all, it’s hard to tell whether a throw is something we throw on our own initiative, or something else that actually causes it.

For example, when using Chrome, Chrome developer tools provides the ability to automatically break the debugger when an exception occurs in the application.

When we turn this function on, the debugger’s break behavior is triggered when we execute the throw in the code below.

This has nothing to do with debugging, and because the throw in the Promise was broken, it seriously affected the functionality provided by the browser.

In the Promise constructor, there is a parameter that specifies the Reject method, and it is easy to use this parameter to set the state of the Promise object to Rejected instead of relying on throw.

What do you do if you want to do reject in THEN, as follows?

What if we call the reject method in then, but only the promise object is passed to the current callback?

Here’s a reminder of how THEN works.

Callbacks registered in THEN can return a value that is passed to subsequent callbacks in then or catch.

Moreover, the return value type of return is not only simple literals, but also complex object types, such as promise objects.

This is a big pity. If the promise object is returned, then according to the state of the Promise object, which of the onFulfilled and onRejected callback functions registered in the next THEN will be called can be determined.

In other words, the retPromise object in the Rejected state calls the onRejected method of the then (reject), thus making it possible to reject (reject) even if the THEN throws are not used.

Use Promise. Reject to simplify the code even further.

In this section we have mainly studied

• Reject is safer than throw

• Use the reject method in then

We probably don’t use reject much in practice, but there are many advantages to using reject over throwing without thinking.

For a more detailed example of this, see the section on cancelling XHR requests using Promise.race and Delay.

Speaking of promises, I’m sure you’ve also heard the term Deferred. JSDeferred[41], JSDeferred[40], JSDeferred[40], JSDeferred[41], JSDeferred[40], JSDeferred[41], JSDeferred[40], JSDeferred[41]

Unlike promises, there is no common specification for Deferred applications, and each Library implements them according to its own preferences.

Here, we intend to center on a similar implementation of jquery.Deferred [42].

Simply put, Deferred and Promise have the following relationship.

• Deferred have Promise

• Deferred has privileged methods to operate on the state of the Promise (” Special Ah10s ソ and Initiate mode “in the figure)

I think it should be easy for you to understand that Deferred and Promise are not in competition, but rather that Deferred implies Promise.

It may be hard to understand just looking at the picture, but let’s look at how to implement a Deferred through a Promise.

An example of implementing a Deferred based on a Promise.

Let’s rewrite getURL, which we implemented with Promise, with Deferred.

Privileged methods that can operate on the Promise state refer to methods that can call resolve, reject, etc., on the state of the Promise object, whereas normal promises can only operate on the state of the Promise object within the method passed through the constructor.

Let’s look at the implementation differences between Deferred and Promise.

Comparing the two versions of getURL, we see the following differences.

• Deferred does not require enclosing the code in promises

  • Because it is not nested in a function, you can reduce the indentation by one layer

  • In turn, there is no error handling logic in Promise

In the following respects, they do the same.

• Overall processing process

  • When to call resolve, reject

• The functions all return promise objects

Because Deferred includes promises, the general flow is similar, but Deferred has privileged methods for working with promises and a high degree of freedom to customize the flow control.

In promises, for example, the main processing logic is written in the constructor, and the timing of the resolve and reject calls is pretty determinate.

With Deferred, you don’t need to write a block of code for the processing logic. You just create a Deferred object that can be called resolve or Reject at any time.

We simply implemented a Deferred above, and I think you can see the difference between this and a Promise.

If promises are used to abstract values and Deferred objects to abstract states or operations that have not yet finished processing, we can understand the difference between the two.

In other words, Promise represents an object. The state of this object is uncertain now, but at a certain point in the future, its state will either become normal or Rejected. This is a big pity. The Deferred object represents the fact that a processing has not yet finished, and when its processing has finished, a Promise can be used to get the result.

If you want to learn more about Deferred, you can refer to the resources below.

First, let’s look at how to implement timeouts in promises.

A timeout is an operation that takes place after a certain amount of time has elapsed.

Let’s start with a simple function that calls setTimeout in a Promise.

DelayPromise (ms) returns an onFulfilled Promise object after the specified number of milliseconds. This is only coded slightly differently than using the setTimeout function directly, as shown below.

The concept of promise objects is very important to keep in mind here.

Let’s review the static method promise.race, which is used to continue processing once any Promise object enters a determined (resolved) state, as shown in the following example.

We can implement a simple timeout mechanism by putting the delayPromise we just mentioned in the promise.race along with other promise objects.

The function timeoutPromise(comparison promise, MS) takes two arguments, the first a promise object that needs to use a timeout mechanism, and the second a timeout, which returns a competing promise object created by promise.race.

We can then use timeoutPromise to write code with a timeout mechanism like the one below.

Although an exception is thrown when a timeout occurs, it is impossible to tell whether the exception is a normal error or a timeout error.

To distinguish the Error object type, we’ll subclass TimeoutError.

The Error object is a build in object built into ECMAScript.

We can’t perfectly create a class that inherits from Error due to stack trace and so on, but our goal here is just to differentiate ourselves from Error, and we’ll create a TimeoutError class to do that.

In order for our TimeoutError to support methods like Error Instanceof TimeoutError, we need to do the following.

We define the TimeoutError class and constructor, which inherits Error’s prototype.

It is used in the same way as a normal Error object, using a throw statement, as shown below.

With this TimeoutError object, it’s easy to distinguish between catching errors that are due to timeouts and errors that are caused by something else.

At this point, I assume you have some idea of how to use Promise to cancel an XHR request.

Canceling the XHR operation itself is not that difficult; just call abort() on the XMLHttpRequest object.

To call abort() externally, the cancelableXHR method returns an ABORT method that cancels the XHR request, in addition to a promise object that wraps the XHR.

Once these questions are understood, all that remains is the flow of Promise processing to code. The general process would look something like this.

1. The cancelableXHR method gets the PROMISE object that wraps the XHR and the method to cancel the XHR request

2. Make XHR’s wrapped promises compete with timeout promises in the timeoutPromise method via promise.race.

   • XHR returns the result before timeout

     1. As with normal promises, the result of the request is returned via then

   • When a timeout occurs

     1. Throw TimeoutError and catch it

     2. Call abort to cancel the XHR request if the catch error object is of type TimeoutError

Summarizing the above steps, the code looks like this.

The above code implements timeout handling with promise objects that become resolved within a certain amount of time.

Earlier in cancelableXHR, the Promise object and its manipulation methods were returned in a single object, which seemed a little confusing.

It’s a good practice from a code organization perspective to return only one value (the promise object) from a function, but since you can’t access the REQ variable created in the cancelableXHR method from the outside, So we need to write a special function (abort in the above example) to handle these internal objects.

You could also consider extending returned Promise objects to support abort methods, but since promise objects are value-abstracted objects, adding methods to the operation without limitation would complicate the whole thing.

We all know that it’s not a good habit to have a function that does too much work, so we don’t want to have a function that does everything, so maybe it’s a good idea to split the function like this.

• Return a Promise object containing XHR

• Accept the Promise object as a parameter and cancel the XHR request in that object

By organizing these processes into a module, you can easily extend them later, the work a function does is more concise, and the code is easier to read and maintain.

There are many ways to create a module (AMD,CommonJS,ES6 Module etc..) CancelableXHR will be used as a node.js module.

Using the method is also very simple. We use the createXHRPromise method to get the XHR promise object. When we abort the XHR, we just pass the promise object to the abortPromise(Promise) method.

Here’s what we learned.

• DelayPromise that becomes resolved after a certain amount of time

• Timeout implementation based on delayPromise and promise.race

• Cancel the XHR Promise request

• The separation of promise objects and actions is achieved through modularity

Promise is a very flexible way to control the processing flow, and to get the most out of it, you need to be careful not to write a function too big and long, but break it up into smaller and simpler processes, and learn more about the mechanisms mentioned earlier in JavaScript.

It should be easy to understand the behavior of the Done method if you look at examples of code that actually uses done.

As mentioned earlier, the Promise design specification doesn’t say anything about promise.prototype. done, so you can either use an implementation provided by your library or implement it yourself.

We’ll talk about how to do this ourselves later, but we’ll start by comparing then with done.

As we can see from the above, there are the following differences between the two.

• Done does not return a Promise object

  • That is, method chains cannot be formed using methods such as catch after done

• Exceptions that occur in done are thrown directly out

  • In other words, there will be no Error Handling as promised

Since done does not return a promise object, it is understandable that it should only appear at the end of a method chain.

In addition, we’ve already seen that Promise has powerful error handling, whereas done skips error handling in functions and throws exceptions directly.

Why do many libraries provide this function that contradicts the Promise feature? Take a look at the following example of how promises handle failures and maybe we can get some idea of why.

Promise has a powerful error-handling mechanism, but it also has a downside: it complicates human errors (when the debugger doesn’t run smoothly).

Maybe you remember when we were in then or Catch? I saw something similar in “.

As follows, let’s look at a function that returns a Promise object.

This function passes the received parameters to json.parse and returns a Promise object based on json.parse.

We can use the Promise function as follows, since json.parse will parse the failure and throw an exception that will be caught by a catch.

This is fine if the failed exception is caught normally, but if you forget to handle the exception when you code, it can be tricky to find the source of the exception once it occurs, which is one aspect of using promises.

Parse (‘ Syntax Error ‘) ¶ Parse (‘ Syntax Error ‘) ¶ parse (‘ Syntax Error ‘) ¶

In this example, we misspelled console as conosle, so the following error occurs.

ReferenceError: conosle is not defined

However, because of the try-catch mechanism of promises, this problem can be internally digested. It would be nice to catch each call without missing anything, but it would be difficult to troubleshoot an error if it occurred during implementation.

The problem of having your mistake digested internally is also called unhandled rejection (Rejected) and has nothing to do with it.

As a methodology, how does done address the above mentioned errors being ignored in Promise? In fact, the method is very simple and straightforward, that is to do error handling.

Since you can implement the done method on promises, let’s look at extending the Promise.prototype.done Promise prototype.

So how does it throw the exception out of the Promise? What we’re actually doing here is using the throw method in setTimeout to throw the exception directly outside.

A closer look at the promise.prototype. done code shows that this function returns nothing. In other words, done is handled according to the principle that “The Promise chain will be interrupted here, and if an exception occurs, just throw it out of the Promise.”

If the implementation and runtime implementation are perfect, unhandled rejection should be done, but not necessarily. In addition, like promise.prototype. done in this section, done can be implemented on top of existing Promises and is not part of ES6 Promises’ design specification.

In this section, we learned the basics and implementation details of done provided by the Promise libraries such as Q, Bluebird[55], and PrFun, and how the done method differs from the THEN method.

We’ve also learned that done has two characteristics.

• Errors in done are thrown as exceptions

• Put an end to Promise chain

And then the or catch? As mentioned in “Promise”, errors that are digested internally by promises may not be a big deal in most cases as debugging tools or libraries improve.

In addition, since done does not return a value, method chains cannot be created after it, so we can use the done method for consistency in the style of the Promise method.

ES6 Promises itself doesn’t offer a lot of features. Therefore, I think we may need to do our own extensions or use third party libraries in many cases.

We struggled to unify asynchronous processing with promises, but going too far could have complicated the system, so keeping the style consistent was an important part of making promises abstract objects.

We will use fs[59] in Node.js as an example.

In addition, the example here focuses on the code being easy to understand, so it may not be very practical in practice.

This module can implement a chain of methods like read → Transform → write below.

The transform accepts as a parameter a method that processes its input parameters. In this example, we prefix the data read with a >> string.

Let’s rewrite the internal implementation using Promise without changing the external interface of the method chain.

The new then and catch additions can be thought of as aliases to internally stored promise objects, while the rest of the parts remain the same from an external interface perspective and are used in the same way as before.

Therefore, when using this module, we only need to change the module name of require.

The file.prototype. then method calls this.promise.then and assigns the returned promise object to the internal promise object of the this.promise variable.

What’s the catch? The following pseudocode makes it easier to understand what’s going on behind the scenes.

See promise = promise.then(…) Writing this way makes it look like the promise will be overwritten, and you might wonder if the promise’s chain has been truncated.

You can think of it as something like promise = addPromiseChain(promise, fn); With this feeling, we added new processing to the Promise object and returned it, so it wouldn’t be a problem if we didn’t implement sequential processing ourselves.

Synchronous and asynchronous

If you’re familiar with Node.js, you might think of Stream[60] when you see a method chain.

Using Stream[61] can eliminate the need to save this.lastValue and improve performance when handling large files. Also, using Stream might be faster than using Promise.

Therefore, it is not necessary to say that promises are always the best choice when processing asynchronously. You should choose the appropriate implementation method based on your purpose and actual situation.

More information about streams in Node.js can be found on the following page.

Back to the FS-method-chain-js and Promise versions, the internal implementation of these two methods is very similar. Is it possible to use the synchronous version of the code as an asynchronous version?

Since JavaScript can add methods to objects dynamically, it should theoretically be possible to automatically generate Promise code from non-Promise versions. (Of course, statically defined implementations are easier to handle.)

Although ES6 Promises does not provide such a feature, bluebird[62], a well-known third-party Promise implementation library, provides a feature called Promisification.

If you use a library like this, you can dynamically add the promise version of methods to an object.

The Promise of Array wrapper

use strict; function ArrayAsPromise(array) { .array = array; .promise = Promise.resolve(); } ArrayAsPromise.prototype. = function (onFulfilled, onRejected) { .promise = .promise.then(onFulfilled, onRejected); return ; }; ArrayAsPromise.prototype[catch] = function (onRejected) { .promise = .promise.catch(onRejected); return ; }; Object.getOwnPropertyNames(Array.prototype).forEach(function (methodName) { // Don't overwrite (typeof ArrayAsPromise[methodName] ! == undefined) { return; } arrayMethod = Array.prototype[methodName]; (typeof arrayMethod ! == function) { return; } ArrayAsPromise.prototype[methodName] = function () { that = ; args = arguments; .promise = .promise.then(function () { that.array = Array.prototype[methodName].apply(that.array, args); return that.array; }); return ; }; }); module.exports = ArrayAsPromise; module.exports.array = function newArrayAsPromise(array) { return ArrayAsPromise(array); };Copy the code

use strict; assert = require(power-assert); ArrayAsPromise = require(.. /src/promise-chain/array-promise-chain); describe(array-promise-chain, function () { function isEven(value) { return value % === ; } function double(value) { return value * ; } beforeEach(function () { .array = [, , , , ]; }); describe(Native array, function () { it(can method chain, function () { result = .array.filter(isEven).map(double); assert.deepEqual(result, [, ]); }); }); describe(ArrayAsPromise, function () { it(can promise chain, function (done) { array = ArrayAsPromise(.array); array.filter(isEven).map(double).then(function (value) { assert.deepEqual(value, [, ]); }).then(done, done); }); }); });Copy the code

In this section we have mainly studied the following contents.

• Promise version of the method chain implementation

• Promise is not always the best choice for asynchronous programming

• Promisification

• Reuse of unified interfaces

ES6 Promises only offers some Core level features. Therefore, we may need to repackage our existing methods in a Promise way.

However, callbacks such as events, which have no limit on how many times they can be called, are not a good place to use Promises, and promises can’t always be the best choice.

When and when you should not use promises is not the purpose of this book. It is important to keep in mind that you should not use promises in everything. I think it is best to consider whether you should use promises or other methods based on your specific purpose and situation.

The implementation in a method that uses multiple THEN iterations is as follows.

As the number of elements in the request increases, we need to increase the number of calls to the then method

Therefore, if we put all the processing content in an array and work with the for loop, the increase in processing content will not be a problem. First we use the for loop to do the same thing as before.

So like promise = promise.then(task).then(pushValue); The code is to continuously process the promise and continuously cover the value of the promise variable to achieve the cumulative processing effect of the Promise object.

This approach, however, requires a temporary variable, promise, which is not as clean from a code-quality perspective.

If you use array.prototype. reduce instead of this loop, the code becomes much smarter.

If the above code were rewritten using array.prototype. reduce, it would look something like this.

With the exception of the main function, everything else in this code is handled the same as when the for loop was used.

The second parameter to array.prototype. reduce sets the initial value for storing computed results. In this example, promise.resolve () is assigned to the Promise, and the task is request.ment.

The value returned from the first argument in reduce will be assigned as a promise for the next loop. That is, by returning a new promise object created by then, you implement a promise chain similar to the for loop.

The difference between using reduce and for loops is that reduce no longer requires the temporary variable PROMISE, so you don’t have to write promise = promise.then(task).then(pushValue); This is a big step forward.

While array.prototype.reduce is great for sequential processing in promises, the code above can be confusing to understand how it works.

So let’s write a function called sequenceTasks, which takes an array of tasks as an argument.

As you can easily imagine from the following call code, the function’s function is to execute the tasks sequentially.

Basically we just need to reconstruct a function based on the reduce method.

One thing to note is that unlike, say, promise.all, this function takes an array of functions as an argument.

Why isn’t an array of Promise objects passed to this function? This is because by the time promise objects are created, XHR is already executing them, so sequential processing of these promise objects will not work properly.

So sequenceTasks takes as an array of functions that return a Promise object.

Finally, use sequenceTasks to rewrite the initial example words, as shown below.

What, is the flow in main() clearer?

As mentioned above, in a Promise, we can choose from several methods to implement sequential execution of the processing.

However, these methods are all based on JavaScript for loops or forEach that operate on arrays and things like that, and are essentially the same. So to some extent, it’s good practice to break up a chunk of processing into smaller functions when dealing with promises.

In this section, we describe how to implement the sequential processing of promises one by one in a Promise, as opposed to promise.all.

In order to realize sequential processing, we also introduced the implementation methods from procedural style coding to custom sequential processing functions, and again emphasized that we should follow the basic principle of dividing processing according to functions in the Promise domain.

You can also make a statement in the source code very long if you use the Promise chain to connect multiple processes in a Promise.

At this point, the overall structure of the code becomes very clear if we recall these basic principles of programming and split functions.

It’s also helpful to realize that Promise constructors and THEN are high-order functions, and that if you split the processing into functions, you can have the side effect of using those functions in flexible combinations.

promise.then(onFulfilled, onRejected);Copy the code

Promise = promise (function(resolve, reject){resolve(pass to then); }); promise.then(function (value) { console.log(value); }, function (error) { console.error(error); });Copy the code

promise.catch(onRejected);Copy the code

Promise = promise (function(resolve, reject){resolve(pass to then); }); promise.then(function (value) { console.log(value); }).catch(function (error) { console.error(error); });Copy the code

Promise.resolve(promise);
Promise.resolve(thenable);
Promise.resolve(object);Copy the code

 taskName = task 1
asyncTask(taskName).then(function (value) {
    console.log(value);
}).catch(function (error) {
    console.error(error);
});
function asyncTask(name){
    return Promise.resolve(name).then(function(value){
        return Done! + value;
    });
}Copy the code

Promise.reject(object)Copy the code

 failureStub = sinon.stub(xhr, request).returns(Promise.reject( Error()));Copy the code

r = Promise.reject( Error(error)); console.log(r === Promise.reject(r)); // falseCopy the code

Promise.all(promiseArray);Copy the code

p1 = Promise.resolve(), p2 = Promise.resolve(), p3 = Promise.resolve(); Promise.all([p1, p2, p3]).then(function (results) { console.log(results); // [1, 2, 3]});Copy the code

Promise.race(promiseArray);Copy the code

 p1 = Promise.resolve(),
    p2 = Promise.resolve(),
    p3 = Promise.resolve();
Promise.race([p1, p2, p3]).then(function (value) {
    console.log(value);  
});Copy the code