* Add Scheduler.unstable_next
* Use Scheduler to prioritize updates
Changes the implementation of syncUpdates, deferredUpdates, and
interactiveUpdates to use runWithPriority, so
This is the minimum integration between Scheduler and React needed to
unblock use of the Scheduler.next API.
* Add Scheduler.unstable_next
* Use Scheduler to prioritize updates
Changes the implementation of syncUpdates, deferredUpdates, and
interactiveUpdates to use runWithPriority, so
This is the minimum integration between Scheduler and React needed to
unblock use of the Scheduler.next API.
Specifying the directory as part of the `repository` field in a `package.json`
allows third party tools to provide better support when working with monorepos.
For example, it allows them to correctly construct a commit diff for a specific
package.
This format was accepted by npm in https://github.com/npm/rfcs/pull/19.
In the process of switching to MessageChannel, it seems the postMessage call was modified to pass `"*"` (originally the target origin value from `window.postMessage`). This actually ends up triggering serialization, whereas passing `undefined` bypasses.
To save some investigation, passing a Number like `0` still incurs serialization overhead - `undefined` has special behavior.
Scheduler needs to schedule a task that fires after paint. To do this,
it currently posts a message event to `window`. This happens on every
frame until the queue is empty. An unfortunate consequence is that every
other message event handler also gets called on every frame; even if
they exit immediately, this adds up to significant per-frame overhead.
Instead, we'll create a MessageChannel and post to that, with a
fallback to the old behavior if MessageChannel does not exist.
* [scheduler] Deadline object -> shouldYield
Instead of using a requestIdleCallback-style deadline object, expose a
method Scheduler.shouldYield that returns true if there's a higher
priority event in the queue.
* Nits
- "Interactive" -> "user-blocking"
- "Whenever" -> "Idle"
These are the terms used by @spanicker in their main-thread scheduling
proposal: https://github.com/spanicker/main-thread-scheduling#api-sketch
That proposal also uses "microtask" instead of "immediate" and "default"
instead of "normal." Not sure about "microtask" because I don't think
most people know what that is. And our implementation isn't a proper
microtask, though you could use it to implement microtasks if you made
sure to wrap every entry point. I don't really have a preference between
"default" and "normal."
These aren't necessarily the final names. Still prefixed by `unstable_`.
* [scheduler] Eagerly schedule rAF at beginning of frame
Eagerly schedule the next animation callback at the beginning of the
frame. If the scheduler queue is not empty at the end of the frame, it
will continue flushing inside that callback. If the queue *is* empty,
then it will exit immediately. Posting the callback at the start of the
frame ensures it's fired within the earliest possible frame. If we
waited until the end of the frame to post the callback, we risk the
browser skipping a frame and not firing the callback until the frame
after that.
* Re-name scheduledCallback -> scheduledHostCallback
This package uses `process.env.NODE_ENV` but does not transform its usage during bundling like the rest of the React libraries do. This causes issues when `process` is not defined globally.
Added some tests for the non-DOM version of Scheduler that is used
as a fallback, e.g. Jest. The tests use Jest's fake timers API:
- `jest.runAllTimers(ms)` flushes all scheduled work, as expected
- `jest.advanceTimersByTime(ms)` flushes only callbacks that expire
within the given milliseconds.
These capabilities should be sufficient for most product tests. Because
jest's fake timers do not override performance.now or Date.now, we
assume time is constant. This means Scheduler's internal time will not
be aligned with other code that reads from `performance.now`. For finer
control, the user can override `window._sched` like we do in our tests.
We will likely publish a Jest package that has this built in.
All of these features are based on features of React's internal
scheduler. The eventual goal is to lift as much as possible out of the
React internals into the Scheduler package.
Includes some renaming of existing methods.
- `scheduleWork` is now `scheduleCallback`
- `cancelScheduledWork` is now `cancelCallback`
Priority levels
---------------
Adds the ability to schedule callbacks at different priority levels.
The current levels are (final names TBD):
- Immediate priority. Fires at the end of the outermost currently
executing (similar to a microtask).
- Interactive priority. Fires within a few hundred milliseconds. This
should only be used to provide quick feedback to the user as a result
of an interaction.
- Normal priority. This is the default. Fires within several seconds.
- "Maybe" priority. Only fires if there's nothing else to do. Used for
prerendering or warming a cache.
The priority is changed using `runWithPriority`:
```js
runWithPriority(InteractivePriority, () => {
scheduleCallback(callback);
});
```
Continuations
-------------
Adds the ability for a callback to yield without losing its place
in the queue, by returning a continuation. The continuation will have
the same expiration as the callback that yielded.
Wrapped callbacks
-----------------
Adds the ability to wrap a callback so that, when it is called, it
receives the priority of the current execution context.
Dan Abramov
zhuoli99
Brian Vaughn
Andrew Clark
Grey Baker
Carl Mungazi
Kevin Chavez
Brian Vaughn
Jason Miller
Nathan Schloss
Minh Nguyen
Sophie Alpert
Trivikram Kamat
Andrew Clark
plievone
Michael Ridgway
Andrew Clark
Dominic Gannaway
Andrew Clark
Maksim Markelov
Heaven