Using microtasks in JavaScript with queueMicrotask()

在此页

Tasks vs microtasks
Using microtasks
范例
另请参阅
相关话题

A microtask is a short function which is executed after the function or program which created it exits and only if the JavaScript execution stack is empty, but before returning control to the event loop being used by the 用户代理 to drive the script's execution environment. This event loop may be either the browser's main event loop or the event loop driving a web worker . This lets the given function run without the risk of interfering with another script's execution, yet also ensures that the microtask runs before the user agent has the opportunity to react to actions taken by the microtask.

JavaScript promises 和 Mutation Observer API both use the microtask queue to run their callbacks, but there are other times when the ability to defer work until the current event loop pass is wrapping up. In order to allow microtasks to be used by third-party libraries, frameworks, and polyfills, the queueMicrotask() method is exposed on the Window and Worker interfaces through the WindowOrWorkerGlobalScope 混合。

Tasks vs microtasks

To properly discuss microtasks, it's first useful to know what a JavaScript task is and how microtasks differ from tasks. This is a quick, simplified explanation, but if you would like more details, you can read the information in the article In depth: Microtasks and the JavaScript runtime environment .

任务

A task is any JavaScript code which is scheduled to be run by the standard mechanisms such as initially starting to run a program, an event callback being run, or an interval or timeout being fired. These all get scheduled on the task queue .

Tasks get added to the task queue when:

A new JavaScript program or subprogram is executed (such as from a console, or by running the code in a <script> element) directly.
An event fires, adding the event's callback function to the task queue.
A timeout or interval created with setTimeout() or setInterval() is reached, causing the corresponding callback to be added to the task queue.

The event loop driving your code handles these tasks one after another, in the order in which they were enqueued. Only tasks which were already in the task queue when the event loop pass began will be executed during the current iteration. The rest will have to wait until the following iteration.

Microtasks

At first the difference between microtasks and tasks seems minor. And they are similar; both are made up of JavaScript code which gets placed on a queue and run at an appropriate time. However, whereas the event loop runs only the tasks present on the queue when the iteration began, one after another, it handles the microtask queue very differently.

There are two key differences.

First, each time a task exits, the event loop checks to see if the task is returning control to other JavaScript code. If not, it runs all of the microtasks in the microtask queue. The microtask queue is, then, processed multiple times per iteration of the event loop, including after handling events and other callbacks.

Second, if a microtask adds more microtasks to the queue by calling queueMicrotask() , those newly-added microtasks execute before the next task is run . That's because the event loop will keep calling microtasks until there are none left in the queue, even if more keep getting added.

警告： Since microtasks can themselves enqueue more microtasks, and the event loop continues processing microtasks until the queue is empty, there's a real risk of getting the event loop endlessly processing microtasks. Be cautious with how you go about recursively adding microtasks.

Using microtasks

Before getting farther into this, it's important to note again that most developers won't use microtasks much, if at all. They're a highly specialized feature of modern browser-based JavaScript development, allowing you to schedule code to jump in front of other things in the long set of things waiting to happen on the user's computer. Abusing this capability will lead to performance problems.

Enqueueing microtasks

As such, you should typically use microtasks only when there's no other solution, or when creating frameworks or libraries that need to use microtasks in order to create the functionality they're implementing. While there have been tricks available that made it possible to enqueue microtasks in the past (such as by creating a promise that resolves immediately), the addition of the queueMicrotask() method adds a standard way to introduce a microtask safely and without tricks.

By introducing queueMicrotask() , the quirks that arise when sneaking in using promises to create microtasks can be avoided. For instance, when using promises to create microtasks, exceptions thrown by the callback are reported as rejected promises rather than being reported as standard exceptions. Also, creating and destroying promises takes additional overhead both in terms of time and memory that a function which properly enqueues microtasks avoids.

Simply pass the JavaScript 函数 to call while the context is handling microtasks into the queueMicrotask() method, which is exposed on the global context as defined by either the Window or Worker interface, depending on the current execution context.

queueMicrotask(() => {
  /* code to run in the microtask here */
});

The microtask function itself takes no parameters, and does not return a value.

When to use microtasks

In this section, we'll take a look at scenarios in which microtasks are particularly useful. Generally, it's about capturing or checking results, or performing cleanup, after the main body of a JavaScript execution context exits, but before any event handlers, timeouts and intervals, or other callbacks are processed.

When is that useful?

The main reason to use microtasks is simply that: to ensure consistent ordering of tasks, even when results or data is available synchronously, but while simultaneously reducing the risk of user-discernible delays in operations.

Ensuring ordering on conditional use of promises

One situation in which microtasks can be used to ensure that the ordering of execution is always consistent is when promises are used in one clause of an if...else statement (or other conditional statement), but not in the other clause. Consider code such as this:

customElement.prototype.getData = url => {
  if (this.cache[url]) {
    this.data = this.cache[url];
    this.dispatchEvent(new Event("load"));
  } else {
    fetch(url).then(result => result.arrayBuffer()).then(data => {
      this.cache[url] = data;
      this.data = data;
      this.dispatchEvent(new Event("load"));
    });
  }
};

The problem introduced here is that by using a task in one branch of the if...else statement (in the case in which the image is available in the cache) but having promises involved in the else clause, we have a situation in which the order of operations can vary; for example, as seen below.

element.addEventListener("load", () => console.log("Loaded data"));
console.log("Fetching data...");
element.getData();
console.log("Data fetched");

Executing this code twice in a row gives the results shown in the table below:

Results when data isn't cached (left) vs. when it is found in the cache
Data isn't cached	Data is cached
Fetching data Data fetched Loaded data	Fetching data Loaded data Data fetched

Even worse, sometimes the element's data property will be set and other times it won't be by the time this code finishes running.

We can ensure consistent ordering of these operations by using a microtask in the if clause to balance the two clauses:

customElement.prototype.getData = url => {
  if (this.cache[url]) {
    queueMicrotask(() => {
      this.data = this.cache[url];
      this.dispatchEvent(new Event("load"));
    });
  } else {
    fetch(url).then(result => result.arrayBuffer()).then(data => {
      this.cache[url] = data;
      this.data = data;
      this.dispatchEvent(new Event("load"));
    });
  }
};

This balances the clauses by having both situations handle the setting of data and firing of the load event within a microtask (using queueMicrotask() 在 if clause and using the promises used by fetch() 在 else clause).

Batching operations

You can also use microtasks to collect multiple requests from various sources into a single batch, avoiding the possible overhead involved with multiple calls to handle the same kind of work.

The snippet below creates a function that batches multiple messages into an array, using a microtask to send them as a single object when the context exits.

const messageQueue = [];
let sendMessage = message => {
  messageQueue.push(message);
  if (messageQueue.length === 1) {
    queueMicrotask(() => {
      const json = JSON.stringify(messageQueue);
      messageQueue.length = 0;
      fetch("url-of-receiver", json);
    });
  }
};

当 sendMessage() gets called, the specified message is first pushed onto the message queue array. Then things get interesting.

If the message we just added to the array is the first one, we enqueue a microtask that will send a batch. The microtask will execute, as always, when the JavaScript execution path reaches the top level, just before running callbacks. That means that any further calls to sendMessage() made in the interim will push their messages onto the message queue, but because of the array length check before adding a microtask, no new microtask is enqueued.

When the microtask runs, then, it has an array of potentially many messages waiting for it. It starts by encoding it as JSON using the JSON.stringify() method. After that, the array's contents aren't needed anymore, so we empty the messageQueue array. Finally, we use the fetch() method to send the JSON string to the server.

This lets every call to sendMessage() made during the same iteration of the event loop add their messages to the same fetch() operation, without potentially having other tasks such as timeouts or the like delay the transmission.

The server will receive the JSON string, then will presumably decode it and process the messages it finds in the resulting array.

范例

Simple microtask example

In this simple example, we see that enqueueing a microtask causes the microtask's callback to run after the body of this top-level script is done running.

HTML

<pre id="log">
</pre>

JavaScript

The code below is used to log the output.

let logElem = document.getElementById("log");
let log = s => logElem.innerHTML += s + "<br>";

In the following code, we see a call to queueMicrotask() used to schedule a microtask to run. This call is bracketed by calls to log() , a custom function that simply outputs text to the screen.

log("Before enqueueing the microtask");
queueMicrotask(() => {
  log("The microtask has run.")
});
log("After enqueueing the microtask");

结果

Timeout and microtask example

In this example, a timeout is scheduled to fire after zero milliseconds (or "as soon as possible"). This demonstrates the difference between what "as soon as possible" means when scheduling a new task (such as by using setTimeout() ) versus using a microtask.

HTML

<pre id="log">
</pre>

JavaScript

The code below is used to log the output.

let logElem = document.getElementById("log");
let log = s => logElem.innerHTML += s + "<br>";

In the following code, we see a call to queueMicrotask() used to schedule a microtask to run. This call is bracketed by calls to log() , a custom function that simply outputs text to the screen.

The code below schedules a timeout to occur in zero milliseconds, then enqueues a microtask. This is bracketed by calls to log() to output additional messages.

let callback = () => log("Regular timeout callback has run");
let urgentCallback = () => log("*** Oh noes! An urgent callback has run!");
log("Main program started");
setTimeout(callback, 0);
queueMicrotask(urgentCallback);
log("Main program exiting");

结果

Note that the output logged from the main program body appears first, followed by the output from the microtask, followed by the timeout's callback. That's because when the task that's handling the execution of the main program exits, the microtask queue gets processed before the task queue on which the timeout callback is located. Remembering that tasks and microtasks are kept on separate queues, and that microtasks run first will help keep this straight.

Microtask from a function

This example expands slightly on the previous one by adding a function that does some work. This function uses queueMicrotask() to schedule a microtask. The important thing to take away from this one is that the microtask isn't processed when the function exits, but when the main program exits.

HTML

<pre id="log">
</pre>

JavaScript

The code below is used to log the output.

let logElem = document.getElementById("log");
let log = s => logElem.innerHTML += s + "<br>";

The main program code follows. The doWork() function here calls queueMicrotask() , yet the microtask still doesn't fire until the entire program exits, since that's when the task exits and there's nothing else on the execution stack.

let callback = () => log("Regular timeout callback has run");
let urgentCallback = () => log("*** Oh noes! An urgent callback has run!");
let doWork = () => {
  let result = 1;
  queueMicrotask(urgentCallback);
  for (let i=2; i<=10; i++) {
    result *= i;
  }
  return result;
};
log("Main program started");
setTimeout(callback, 0);
log(`10! equals ${doWork()}`);
log("Main program exiting");

结果

另请参阅

元数据

最后修改： Jan 6, 2020

在此页

Tasks vs microtasks

任务

Microtasks

Using microtasks

Enqueueing microtasks

When to use microtasks

Ensuring ordering on conditional use of promises

Batching operations

范例

Simple microtask example

HTML

JavaScript

结果

Timeout and microtask example

HTML

JavaScript

结果

Microtask from a function

HTML

JavaScript

结果

另请参阅

相关话题