worker-timers 7.0.51 → 7.0.54

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (2) hide show
  1. package/README.md +20 -49
  2. package/package.json +17 -17
package/README.md CHANGED
@@ -4,32 +4,24 @@
4
4
 
5
5
  **A replacement for setInterval() and setTimeout() which works in unfocused windows.**
6
6
 
7
- [![dependencies](https://img.shields.io/david/chrisguttandin/worker-timers.svg?style=flat-square)](https://github.com/chrisguttandin/worker-timers/network/dependencies)
8
7
  [![version](https://img.shields.io/npm/v/worker-timers.svg?style=flat-square)](https://www.npmjs.com/package/worker-timers)
9
8
 
10
9
  ## Motivation
11
10
 
12
- For scripts that rely on [WindowTimers](http://www.w3.org/TR/html5/webappapis.html#timers) like
13
- setInterval() or setTimeout() things get confusing when the site which the script is running on
14
- loses focus. Chrome, Firefox and maybe others throttle the frequency of firing those timers to a
15
- maximum of once per second in such a situation. However this is only true for the main thread and
16
- does not affect the behavior of [Web Workers](http://www.w3.org/TR/workers/). Therefore it is
17
- possible to avoid the throttling by using a worker to do the actual scheduling. This is exactly what
18
- WorkerTimers do.
11
+ For scripts that rely on [WindowTimers](http://www.w3.org/TR/html5/webappapis.html#timers) 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](http://www.w3.org/TR/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.
19
12
 
20
13
  ## Getting Started
21
14
 
22
- WorkerTimers are available as a package on [npm](https://www.npmjs.org/package/worker-timers).
23
- Simply run the following command to install it:
15
+ `worker-timers` is available as a package on [npm](https://www.npmjs.org/package/worker-timers). Run the following command to install it:
24
16
 
25
17
  ```shell
26
18
  npm install worker-timers
27
19
  ```
28
20
 
29
- You can then require the workerTimers instance from within your code like this:
21
+ You can then import the exported functions in your code like this:
30
22
 
31
23
  ```js
32
- import * as workerTimers from 'worker-timers';
24
+ import { clearInterval, clearTimeout, setInterval, setTimeout } from 'worker-timers';
33
25
  ```
34
26
 
35
27
  The usage is exactly the same (despite of the [error handling](#error-handling) and the
@@ -37,40 +29,34 @@ The usage is exactly the same (despite of the [error handling](#error-handling)
37
29
  as with the corresponding functions on the global scope.
38
30
 
39
31
  ```js
40
- var intervalId = workerTimers.setInterval(() => {
32
+ var intervalId = setInterval(() => {
41
33
  // do something many times
42
34
  }, 100);
43
35
 
44
- workerTimers.clearInterval(intervalId);
36
+ clearInterval(intervalId);
45
37
 
46
- var timeoutId = workerTimers.setTimeout(() => {
38
+ var timeoutId = setTimeout(() => {
47
39
  // do something once
48
40
  }, 100);
49
41
 
50
- workerTimers.clearTimeout(timeoutId);
42
+ clearTimeout(timeoutId);
51
43
  ```
52
44
 
53
45
  ## Error Handling
54
46
 
55
- The native WindowTimers are very forgiving. Calling `clearInterval()` or `clearTimeout()` without
56
- a value or with an id which doesn't exist will just get ignored. In contrast to that workerTimers
57
- will throw an error when doing so.
47
+ The native WindowTimers are very forgiving. Calling `clearInterval()` or `clearTimeout()` without a value or with an id which doesn't exist will get ignored. In contrast to that `worker-timers` will throw an error when doing so.
58
48
 
59
49
  ```js
60
- // This will just return undefined.
61
- window.clearTimeout('not-an-timeout-id');
50
+ // This will return undefined.
51
+ window.clearTimeout('not-a-timeout-id');
62
52
 
63
53
  // This will throw an error.
64
- workerTimers.clearTimeout('not-an-timeout-id');
54
+ clearTimeout('not-a-timeout-id');
65
55
  ```
66
56
 
67
57
  ## Differentiation between Intervals and Timeouts
68
58
 
69
- Another difference between workerTimers and WindowTimers is that this package maintains two
70
- separate lists to store the ids of intervals and timeouts internally. WindowTimers do only have one
71
- list which allows intervals to be cancelled by calling `clearTimeout()` and the other way round.
72
- This is not possible with workerTimers. As mentioned above workerTimers will throw an error when
73
- provided with an unknown id.
59
+ Another difference between `worker-timers` and WindowTimers is that this package maintains two separate lists to store the ids of intervals and timeouts internally. WindowTimers do only have one list which allows intervals to be cancelled by calling `clearTimeout()` and the other way round. This is not possible with `worker-timers`. As mentioned above `worker-timers` will throw an error when provided with an unknown id.
74
60
 
75
61
  ```js
76
62
  const periodicWork = () => {};
@@ -80,29 +66,14 @@ const windowId = window.setInterval(periodicWork, 100);
80
66
  window.clearTimeout(windowId);
81
67
 
82
68
  // This will throw an error.
83
- const workerId = workerTimers.setInterval(periodicWork, 100);
84
- workerTimers.clearTimeout(workerId);
69
+ const workerId = setInterval(periodicWork, 100);
70
+ clearTimeout(workerId);
85
71
  ```
86
72
 
87
73
  ## Server-Side Rendering
88
74
 
89
- This package is intended to be used in the browser and requires the browser to have [support for
90
- Web Workers](https://caniuse.com/#feat=webworkers). It does not contain any fallback which would
91
- allow it to run in another environment like Node.js which doesn't know about Web Workers. This is to
92
- prevent this package from silently failing in an unsupported browser. But it also means that it
93
- needs to be replaced when used in a web project which also supports server-side rendering. That
94
- should be easy, at least in theory, because each function has the exact same signature as its
95
- corresponding builtin function. But the configuration of a real-life project can of course be
96
- tricky. For a concrete example, please have a look at the
97
- [worker-timers-ssr-example](https://github.com/newyork-anthonyng/worker-timers-ssr-example)
98
- provided by [@newyork-anthonyng](https://github.com/newyork-anthonyng). It shows the usage inside
99
- of a server-side rendered React app.
100
-
101
- ## Angular (& zone.js)
102
-
103
- If WorkerTimers are used inside of an Angular App and Zones are used to detect changes, the
104
- behavior of WorkerTimers can be confusing. Angular is using a Zone which is patching the native
105
- setInterval() and setTimeout() functions to get notified about the execution of their callback
106
- functions. But Angular (more specifically zone.js) is not aware of WorkerTimers and doesn't patch
107
- them. Therefore Angular needs to be notified manually about state changes that occur inside of a
108
- callback function which was scheduled with the help of WorkerTimers.
75
+ This package is intended to be used in the browser and requires the browser to have [support for Web Workers](https://caniuse.com/#feat=webworkers). 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](https://github.com/newyork-anthonyng/worker-timers-ssr-example) provided by [@newyork-anthonyng](https://github.com/newyork-anthonyng). It shows the usage inside of a server-side rendered React app.
76
+
77
+ ## Angular (& Zone.js)
78
+
79
+ 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`.
package/package.json CHANGED
@@ -15,27 +15,27 @@
15
15
  }
16
16
  ],
17
17
  "dependencies": {
18
- "@babel/runtime": "^7.18.9",
18
+ "@babel/runtime": "^7.19.0",
19
19
  "tslib": "^2.4.0",
20
- "worker-timers-broker": "^6.0.73",
21
- "worker-timers-worker": "^7.0.40"
20
+ "worker-timers-broker": "^6.0.76",
21
+ "worker-timers-worker": "^7.0.42"
22
22
  },
23
23
  "description": "A replacement for setInterval() and setTimeout() which works in unfocused windows.",
24
24
  "devDependencies": {
25
- "@babel/core": "^7.18.9",
25
+ "@babel/core": "^7.19.0",
26
26
  "@babel/plugin-external-helpers": "^7.18.6",
27
- "@babel/plugin-transform-runtime": "^7.18.9",
28
- "@babel/preset-env": "^7.18.9",
29
- "@commitlint/cli": "^17.0.3",
30
- "@commitlint/config-angular": "^17.0.3",
27
+ "@babel/plugin-transform-runtime": "^7.18.10",
28
+ "@babel/preset-env": "^7.19.0",
29
+ "@commitlint/cli": "^17.1.2",
30
+ "@commitlint/config-angular": "^17.1.0",
31
31
  "@rollup/plugin-babel": "^5.3.1",
32
32
  "@rollup/plugin-replace": "^4.0.0",
33
33
  "babel-loader": "^8.2.5",
34
34
  "chai": "^4.3.6",
35
35
  "commitizen": "^4.2.5",
36
36
  "cz-conventional-changelog": "^3.3.0",
37
- "eslint": "^8.20.0",
38
- "eslint-config-holy-grail": "^52.0.22",
37
+ "eslint": "^8.23.0",
38
+ "eslint-config-holy-grail": "^52.0.32",
39
39
  "grunt": "^1.5.3",
40
40
  "grunt-cli": "^1.4.3",
41
41
  "grunt-sh": "^0.2.0",
@@ -54,16 +54,16 @@
54
54
  "prettier": "^2.7.1",
55
55
  "pretty-quick": "^3.1.3",
56
56
  "rimraf": "^3.0.2",
57
- "rollup": "^2.77.0",
57
+ "rollup": "^2.79.0",
58
58
  "sinon": "^14.0.0",
59
59
  "sinon-chai": "^3.7.0",
60
- "terser-webpack-plugin": "^5.3.3",
60
+ "terser-webpack-plugin": "^5.3.6",
61
61
  "ts-loader": "^9.3.1",
62
- "tsconfig-holy-grail": "^11.1.34",
62
+ "tsconfig-holy-grail": "^11.1.36",
63
63
  "tslint": "^6.1.3",
64
- "tslint-config-holy-grail": "^53.2.30",
65
- "typescript": "^4.7.4",
66
- "webpack": "^5.73.0",
64
+ "tslint-config-holy-grail": "^53.2.33",
65
+ "typescript": "^4.8.2",
66
+ "webpack": "^5.74.0",
67
67
  "webpack-cli": "^4.10.0"
68
68
  },
69
69
  "files": [
@@ -95,5 +95,5 @@
95
95
  "test": "grunt lint && grunt test"
96
96
  },
97
97
  "types": "build/es2019/module.d.ts",
98
- "version": "7.0.51"
98
+ "version": "7.0.54"
99
99
  }