main-thread-scheduling - npm Package Compare versions

Comparing version 5.0.0 to 5.0.1

package.json

		{
		"name": "main-thread-scheduling",
		"version": "5.0.0",
		"version": "5.0.1",
		"description": "Consistently responsive apps while staying on the main thread",
		@@ -5,0 +5,0 @@ "license": "MIT",

readme.md

		@@ -15,4 +15,4 @@ <br>
		<p align="center">
		<a href="https://www.travis-ci.com/astoilkov/main-thread-scheduling">
		<img src="https://www.travis-ci.com/astoilkov/main-thread-scheduling.svg?branch=master" alt="Build Status" />
		<a href="https://bundlephobia.com/result?p=main-thread-scheduling">
		<img src="https://badgen.net/bundlephobia/minzip/main-thread-scheduling" alt="Gzipped Size" />
		</a>
		@@ -22,4 +22,4 @@ <a href="https://codeclimate.com/github/astoilkov/main-thread-scheduling/test_coverage">
		</a>
		<a href="https://bundlephobia.com/result?p=main-thread-scheduling">
		<img src="https://badgen.net/bundlephobia/min/main-thread-scheduling" alt="Minified Size" />
		<a href="https://www.travis-ci.com/astoilkov/main-thread-scheduling">
		<img src="https://www.travis-ci.com/astoilkov/main-thread-scheduling.svg?branch=master" alt="Build Status" />
		</a>
		@@ -62,6 +62,6 @@ <p>
		Why rely on some open-source library to ensure a good performance for my app?
		- Not a weekend project. I've already been using it for a year in two of my products — [Nota](https://nota.md) and [iBar](https://ibar.app). If you want to dive deeper, you can read the [in-depth](./docs/in-depth-overview.md) doc.
		- Not a weekend project. I've already been using it for over a year in the core of two of my products — [Nota](https://nota.md) and [iBar](https://ibar.app). If you want to dive deeper, you can read the [in-depth](./docs/in-depth-overview.md) doc.
		- This is the future. Browsers are probably going to support scheduling tasks on the main thread in the future. Here is the [spec](https://github.com/WICG/scheduling-apis). This library will still be relevant in the future because it provides an easier API.
		- Simple. 90% of the time you only need `yieldOrContinue(priority)` function. The API has two more functions for more advanced cases.
		- Aiming for high-quality with [my open-source principles](https://astoilkov.com/my-open-source-principles).
		- High quality. Aiming for high-quality with [my open-source principles](https://astoilkov.com/my-open-source-principles).

		@@ -68,0 +68,0 @@ ## Example

src/phaseTracking.js

		@@ -32,5 +32,9 @@ import nextTask from './nextTask';
		// #connection 2021-06-05T3:07:18+03:00
		// call at least once per frame
		// assuming 60 fps, 1000/60 = 16.667
		timeout: 16,
		// - call at least once per frame
		// - assuming 60 fps, 1000/60 = 16.667 = 16.7
		// - the browser uses around 6ms. the user is left with 10ms:
		// https://developer.mozilla.org/en-US/docs/Web/Performance/How_long_is_too_long#:~:text=The%2016.7%20milliseconds%20includes%20scripting%2C%20reflow%2C%20and%20repaint.%20Realize%20a%20document%20takes%20about%206ms%20to%20render%20a%20frame%2C%20leaving%20about%2010ms%20for%20the%20rest.
		// - because 9*2 is equal to 18, we are sure the idle callback won't be called more than
		// once per frame
		timeout: 9,
		});
		@@ -56,5 +60,5 @@ }
		// Why the "stop-requested" status?
		// - we request to stop the tracking of IdlePhase becuase later in a microtask we may call
		// - we request to stop the tracking of IdlePhase because later in a microtask we may call
		// `startTrackingIdlePhase()` again. all the steps below happen in a single browser task (in
		// multiple brwoser micro tasks):
		// multiple browser micro tasks):
		// 1. `stopTrackingIdlePhase()` is called
		@@ -61,0 +65,0 @@ // 2. Promise for `yieldControl()` resolves

src/promiseEscape.d.ts

		/**
		* If called at the end of an async method, it will wait for the the async to get resolved in the
		* If called at the end of an async method, it will wait for the async to get resolved in the
		* parent method that called it and will execute the provided callback in the next microtask.
		@@ -4,0 +4,0 @@ * @param callback {Function} The callback that will be executed.

src/promiseEscape.js

		@@ -5,3 +5,3 @@ import requestLaterMicrotask from './requestLaterMicrotask';
		/**
		* If called at the end of an async method, it will wait for the the async to get resolved in the
		* If called at the end of an async method, it will wait for the async to get resolved in the
		* parent method that called it and will execute the provided callback in the next microtask.
		@@ -8,0 +8,0 @@ * @param callback {Function} The callback that will be executed.

src/yieldControl.js

		@@ -28,5 +28,9 @@ import nextTask from './nextTask';
		// #connection 2021-06-05T3:07:18+03:00
		// call at least once per frame
		// assuming 60 fps, 1000/60 = 16.667
		timeout: 16,
		// - call at least once per frame
		// - assuming 60 fps, 1000/60 = 16.667 = 16.7
		// - the browser uses around 6ms. the user is left with 10ms:
		// https://developer.mozilla.org/en-US/docs/Web/Performance/How_long_is_too_long#:~:text=The%2016.7%20milliseconds%20includes%20scripting%2C%20reflow%2C%20and%20repaint.%20Realize%20a%20document%20takes%20about%206ms%20to%20render%20a%20frame%2C%20leaving%20about%2010ms%20for%20the%20rest.
		// - because 9*2 is equal to 18, we are sure the idle callback won't be called more than
		// once per frame
		timeout: 9,
		});
		@@ -33,0 +37,0 @@ }

main-thread-scheduling - npm Package Compare versions

New alerts

Fixed alerts

Improved metrics