Gathering detailed insights and metrics for worker-timers
Gathering detailed insights and metrics for worker-timers
Gathering detailed insights and metrics for worker-timers
Gathering detailed insights and metrics for worker-timers
A replacement for setInterval() and setTimeout() which works in unfocused windows.
npm install worker-timers
Module System
Min. Node Version
Typescript Support
Node Version
NPM Version
595 Stars
4,384 Commits
25 Forks
5 Watching
1 Branches
3 Contributors
Updated on 22 Nov 2024
JavaScript (86.96%)
TypeScript (13.04%)
Cumulative downloads
Total Downloads
Last day
-7%
61,284
Compared to previous day
Last week
3.2%
334,961
Compared to previous week
Last month
18.5%
1,340,541
Compared to previous month
Last year
573.5%
7,950,277
Compared to previous year
45
A replacement for setInterval() and setTimeout() which works in unfocused windows.
For scripts that rely on WindowTimers like setInterval()
or setTimeout()
things get confusing when the site which the script is running on loses focus. Chrome, Firefox and maybe others throttle the frequency at which they invoke those timers to a maximum of once per second in such a situation. However this is only true for the main thread and does not affect the behavior of Web Workers. Therefore it is possible to avoid the throttling by using a worker to do the actual scheduling. This is exactly what worker-timers
does.
worker-timers
is available as a package on npm. Run the following command to install it:
1npm install worker-timers
You can then import the exported functions in your code like this:
1import { clearInterval, clearTimeout, setInterval, setTimeout } from 'worker-timers';
The usage is exactly the same (despite of the error handling and the differentiation between intervals and timeouts) as with the corresponding functions on the global scope.
1var intervalId = setInterval(() => { 2 // do something many times 3}, 100); 4 5clearInterval(intervalId); 6 7var timeoutId = setTimeout(() => { 8 // do something once 9}, 100); 10 11clearTimeout(timeoutId);
The native WindowTimers only maintain a single list of timers. But worker-timers
maintains two separate lists to store the ids of intervals and timeouts internally. WindowTimers allows intervals to be cancelled by calling clearTimeout()
and the other way round because it stores all timers in a single list. This is not possible with worker-timers
.
1const periodicWork = () => {};
2
3// This will stop the interval.
4const windowId = window.setInterval(periodicWork, 100);
5window.clearTimeout(windowId);
6
7// This will not cancel the interval. It may cancel a timeout.
8const workerId = setInterval(periodicWork, 100);
9clearTimeout(workerId);
This package is intended to be used in the browser and requires the browser to have support for Web Workers. It does not contain any fallback which would allow it to run in another environment like Node.js which doesn't know about Web Workers. This is to prevent this package from silently failing in an unsupported browser. But it also means that it needs to be replaced when used in a web project which also supports server-side rendering. The replacement should be straightforward, at least in theory, because each function has the exact same signature as its corresponding builtin function. But the configuration of a real-life project can be tricky. For a concrete example, please have a look at the worker-timers-ssr-example provided by @newyork-anthonyng. It shows the usage inside of a server-side rendered React app.
If worker-timers
is used inside of an Angular app and Zone.js (which is the default) is used to detect changes, the behavior of worker-timers
can be confusing. Angular is using Zone.js which is patching the native setInterval()
and setTimeout()
functions to get notified about the invocation of their callback functions. But Angular (more specifically Zone.js) is not aware of worker-timers
and doesn't get notified about any callback invocations. Therefore Angular needs to be notified manually about state changes that occur inside of a callback function which was scheduled with the help of worker-timers
.
To report a security vulnerability, please use the Tidelift security contact. Tidelift will coordinate the fix and disclosure.
No vulnerabilities found.
Reason
no dangerous workflow patterns detected
Reason
30 commit(s) and 2 issue activity found in the last 90 days -- score normalized to 10
Reason
no binaries found in the repo
Reason
license file detected
Details
Reason
6 existing vulnerabilities detected
Details
Reason
dependency not pinned by hash detected -- score normalized to 2
Details
Reason
detected GitHub workflow tokens with excessive permissions
Details
Reason
Found 0/30 approved changesets -- score normalized to 0
Reason
no SAST tool detected
Details
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
security policy file not detected
Details
Reason
project is not fuzzed
Details
Reason
branch protection not enabled on development/release branches
Details
Score
Last Scanned on 2024-11-25
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More