search
element with form functionality — Last Updated 1 December 2021The setTimeout()
and setInterval()
methods allow authors to schedule timer-based
callbacks.
id = self.setTimeout(handler [, timeout [, ...arguments ] ])
Schedules a timeout to run handler after timeout milliseconds. Any arguments are passed straight through to the handler.
id = self.setTimeout(code [, timeout ])
Schedules a timeout to compile and run code after timeout milliseconds.
self.clearTimeout(id)
Cancels the timeout set with setTimeout()
or setInterval()
identified by id.
id = self.setInterval(handler [, timeout [, ...arguments ] ])
Schedules a timeout to run handler every timeout milliseconds. Any arguments are passed straight through to the handler.
id = self.setInterval(code [, timeout ])
Schedules a timeout to compile and run code every timeout milliseconds.
self.clearInterval(id)
Cancels the timeout set with setInterval()
or setTimeout()
identified by id.
Timers can be nested; after five such nested timers, however, the interval is forced to be at least four milliseconds.
This API does not guarantee that timers will run exactly on schedule. Delays due to CPU load, other tasks, etc, are to be expected.
To run tasks of several milliseconds back to back without any delay, while still yielding back to the browser to avoid starving the user interface (and to avoid the browser killing the script for hogging the CPU), simply queue the next timer before performing work:
function doExpensiveWork() {
var done = false ;
// ...
// this part of the function takes up to five milliseconds
// set done to true if we're done
// ...
return done;
}
function rescheduleWork() {
var id = setTimeout( rescheduleWork, 0 ); // preschedule next iteration
if ( doExpensiveWork())
clearTimeout( id); // clear the timeout if we don't need it
}
function scheduleWork() {
setTimeout( rescheduleWork, 0 );
}
scheduleWork(); // queues a task to do lots of work
Support in all current engines.
self.queueMicrotask(callback)
Queues a microtask to run the given callback.
The queueMicrotask()
method allows authors to schedule
a callback on the microtask queue. This allows their code to run once the
JavaScript execution context stack is next empty, which happens once all currently
executing synchronous JavaScript has run to completion. This doesn't yield control back to the
event loop, as would be the case when using, for example, setTimeout(f, 0)
.
Authors ought to be aware that scheduling a lot of microtasks has the same performance
downsides as running a lot of synchronous code. Both will prevent the browser from doing its own
work, such as rendering. In many cases, requestAnimationFrame()
or
requestIdleCallback()
is a better choice. In particular, if the goal is to run code
before the next rendering cycle, that is the purpose of requestAnimationFrame()
.
As can be seen from the following examples, the best way of thinking about queueMicrotask()
is as a mechanism for rearranging synchronous
code, effectively placing the queued code immediately after the currently executing synchronous
JavaScript has run to completion.
The most common reason for using queueMicrotask()
is
to create consistent ordering, even in the cases where information is available synchronously,
without introducing undue delay.
For example, consider a custom element firing a load
event, that also
maintains an internal cache of previously-loaded data. A naïve implementation might look
like:
MyElement. prototype. loadData = function ( url) {
if ( this . _cache[ url]) {
this . _setData( this . _cache[ url]);
this . dispatchEvent( new Event( "load" ));
} else {
fetch( url). then( res => res. arrayBuffer()). then( data => {
this . _cache[ url] = data;
this . _setData( data);
this . dispatchEvent( new Event( "load" ));
});
}
};
This naïve implementation is problematic, however, in that it causes its users to experience inconsistent behavior. For example, code such as
element. addEventListener( "load" , () => console. log( "loaded" ));
console. log( "1" );
element. loadData();
console. log( "2" );
will sometimes log "1, 2, loaded" (if the data needs to be fetched), and sometimes log "1,
loaded, 2" (if the data is already cached). Similarly, after the call to loadData()
, it will be inconsistent whether or not the data is set on the
element.
To get a consistent ordering, queueMicrotask()
can be
used:
MyElement. prototype. loadData = function ( url) {
if ( this . _cache[ url]) {
queueMicrotask(() => {
this . _setData( this . _cache[ url]);
this . dispatchEvent( new Event( "load" ));
});
} else {
fetch( url). then( res => res. arrayBuffer()). then( data => {
this . _cache[ url] = data;
this . _setData( data);
this . dispatchEvent( new Event( "load" ));
});
}
};
By essentially rearranging the queued code to be after the JavaScript execution context stack empties, this ensures a consistent ordering and update of the element's state.
Another interesting use of queueMicrotask()
is to
allow uncoordinated "batching" of work by multiple callers. For example, consider a library
function that wants to send data somewhere as soon as possible, but doesn't want to make multiple
network requests if doing so is easily avoidable. One way to balance this would be like so:
const queuedToSend = [];
function sendData( data) {
queuedToSend. push( data);
if ( queuedToSend. length === 1 ) {
queueMicrotask(() => {
const stringToSend = JSON. stringify( queuedToSend);
queuedToSend. length = 0 ;
fetch( "/endpoint" , stringToSend);
});
}
}
With this architecture, multiple subsequent calls to sendData()
within
the currently executing synchronous JavaScript will be batched together into one
fetch()
call, but with no intervening event loop tasks preempting the fetch (as
would have happened with similar code that instead used setTimeout()
).
window.alert(message)
Displays a modal alert with the given message, and waits for the user to dismiss it.
result = window.confirm(message)
Displays a modal OK/Cancel prompt with the given message, waits for the user to dismiss it, and returns true if the user clicks OK and false if the user clicks Cancel.
result = window.prompt(message [, default])
Displays a modal text control prompt with the given message, waits for the user to dismiss it, and returns the value that the user entered. If the user cancels the prompt, then returns null instead. If the second argument is present, then the given value is used as a default.
Logic that depends on tasks or microtasks, such as media elements loading their media data, are stalled when these methods are invoked.
Support in all current engines.
window.print()
Prompts the user to print the page.