{{APIRef("HTML DOM")}}
マイクロタスク は、それを作成する関数/プログラムが終了した後、JavaScript実行スタックが空な場合のみに、スクリプトの実行環境を動かしている{{Glossary("user agent")}}が使っているイベントループに制御が戻る前に実行される短い関数です。このイベントループはブラウザーのメインのイベントループと、web workerが動かしているイベントループのいずれかです。 これにより、ある関数が他のスクリプトの実行に干渉するリスクを除外して実行できます。またマイクロタスクが取ったアクションにユーザーエージェントが反応するよりも前に、マイクロタスクを確実に実行させることもできます。
JavaScript promises and the 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 {{domxref("WindowOrWorkerGlobalScope.queueMicrotask", "queueMicrotask()")}} method is exposed on the {{domxref("Window")}} and {{domxref("Worker")}} interfaces through the {{domxref("WindowOrWorkerGlobalScope")}} mixin.
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:
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.
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 {{domxref("WindowOrWorkerGlobalScope.queueMicrotask", "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.
Warning: 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.
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.
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 {{domxref("WindowOrWorkerGlobalScope.queueMicrotask", "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 {{jsxref("Function")}} to call while the context is handling microtasks into the queueMicrotask() method, which is exposed on the global context as defined by either the {{domxref("Window")}} or {{domxref("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.
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.
実行順序が常に一貫するよう保証するためにマイクロタスクを使用できる状況として、Promiseが単一の if...else 文 (や他の条件文)の句の中にあって、他の句の内にないときです。次のコードを考えてみます:
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"));
)};
}
};
ここで入ってきた問題は、if...else 文 (画像がキャッシュ内で利用できる場合) の分岐内でタスクを使っているが、else 句でPromiseがある場合、命令の順序が変わる状況になります; 例えば、次のように。
element.addEventListener("load", () => console.log("Loaded data"));
console.log("Fetching data...");
element.getData();
console.log("Data fetched");
このコードを行の中で2回実行すると、次の表の結果になります:
| データはキャッシュされていない | データはキャッシュされている |
|---|---|
Fetching data Data fetched Loaded data |
Fetching data Loaded data Data fetched |
もっと悪いことに、このコードが実行完了となるまでに、要素の data プロパティは時々セットされたり、されなかったりもします。
これらの命令の順序を一貫させるために、マイクロタスクを if 句の中で使って、2つの句のバランスを取ることができます:
customElement.prototype.getData = url => {
if (thiscache[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"));
)};
}
};
両方の状況でマイクロタスク内で data をセットして load イベントを発火させる (if 句では queueMicrotask()を使い else 句では{{domxref("WindowOrWorkerGlobalScope.fetch", "fetch()")}} を使う) ことで、句ごとにバランスを取っています。
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);
});
}
};
When 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 {{jsxref("JSON.stringify()")}} method. After that, the array's contents aren't needed anymore, so we empty the messageQueue array. Finally, we use the {{domxref("WindowOrWorkerGlobalScope.fetch", "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.
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.
<pre id="log"> </pre>
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 {{domxref("WindowOrWorkerGlobalScope.queueMicrotask", "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");
{{EmbedLiveSample("Simple_microtask_example", 640, 80)}}
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.
<pre id="log"> </pre>
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 {{domxref("WindowOrWorkerGlobalScope.queueMicrotask", "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");
{{EmbedLiveSample("Timeout_and_microtask_example", 640, 100)}}
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.
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.
<pre id="log"> </pre>
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");
{{EmbedLiveSample("Microtask_from_a_function", 640, 100)}}