2015-02-20 04:10:52 +00:00
|
|
|
/**
|
2015-03-23 20:35:08 +00:00
|
|
|
* Copyright (c) 2015-present, Facebook, Inc.
|
|
|
|
* All rights reserved.
|
|
|
|
*
|
|
|
|
* This source code is licensed under the BSD-style license found in the
|
|
|
|
* LICENSE file in the root directory of this source tree. An additional grant
|
|
|
|
* of patent rights can be found in the PATENTS file in the same directory.
|
2015-02-20 04:10:52 +00:00
|
|
|
*
|
|
|
|
* @providesModule InteractionManager
|
2015-03-26 17:06:50 +00:00
|
|
|
* @flow
|
2015-02-20 04:10:52 +00:00
|
|
|
*/
|
|
|
|
'use strict';
|
|
|
|
|
Add yieldy, chained async task support to InteractionManager
Summary:
Default behavior should be unchanged.
If we queue up a bunch of expensive tasks during an interaction, the default
`InteractionManager` behavior would execute them all in one synchronous loop at
the end the JS event loop via one `setImmediate` call, blocking the JS thread
the entire time.
The `setDeadline` addition in this diff enables an option to only execute tasks
until the `eventLoopRunningTime` is hit (added to MessageQueue/BatchedBridge),
allowing the queue execution to be paused if an interaction starts in between
tasks, making the app more responsive.
Additionally, if a task ends up generating a bunch of additional tasks
asynchronously, the previous implementation would execute these new tasks after
already scheduled tasks. This is often fine, but I want it to fully resolve
async tasks and all their dependencies before making progress in the rest of the
queue, so I added support for `type PromiseTask = {gen: () => Promise}` to do
just this. It works by building a stack of queues each time a `PromiseTask` is
started, and pops them off the stack once they are resolved and the queues are
processed.
I also pulled all of the actual queue logic out of `InteractionManager` and into
a new `TaskQueue` class to isolate concerns a bit.
public
Reviewed By: josephsavona
Differential Revision: D2754311
fb-gh-sync-id: bfd6d0c54e6410cb261aa1d2c5024dd91a3959e6
2015-12-24 00:10:39 +00:00
|
|
|
const BatchedBridge = require('BatchedBridge');
|
|
|
|
const EventEmitter = require('EventEmitter');
|
|
|
|
const Set = require('Set');
|
|
|
|
const TaskQueue = require('TaskQueue');
|
2015-02-20 04:10:52 +00:00
|
|
|
|
2016-06-09 05:54:19 +00:00
|
|
|
const infoLog = require('infoLog');
|
2016-03-02 12:27:13 +00:00
|
|
|
const invariant = require('fbjs/lib/invariant');
|
2017-09-06 10:25:01 +00:00
|
|
|
/* $FlowFixMe(>=0.54.0 site=react_native_oss) This comment suppresses an error
|
|
|
|
* found when Flow v0.54 was deployed. To see the error delete this comment and
|
|
|
|
* run Flow. */
|
2016-03-02 12:27:13 +00:00
|
|
|
const keyMirror = require('fbjs/lib/keyMirror');
|
2015-02-20 04:10:52 +00:00
|
|
|
|
2015-05-20 23:53:24 +00:00
|
|
|
type Handle = number;
|
Add yieldy, chained async task support to InteractionManager
Summary:
Default behavior should be unchanged.
If we queue up a bunch of expensive tasks during an interaction, the default
`InteractionManager` behavior would execute them all in one synchronous loop at
the end the JS event loop via one `setImmediate` call, blocking the JS thread
the entire time.
The `setDeadline` addition in this diff enables an option to only execute tasks
until the `eventLoopRunningTime` is hit (added to MessageQueue/BatchedBridge),
allowing the queue execution to be paused if an interaction starts in between
tasks, making the app more responsive.
Additionally, if a task ends up generating a bunch of additional tasks
asynchronously, the previous implementation would execute these new tasks after
already scheduled tasks. This is often fine, but I want it to fully resolve
async tasks and all their dependencies before making progress in the rest of the
queue, so I added support for `type PromiseTask = {gen: () => Promise}` to do
just this. It works by building a stack of queues each time a `PromiseTask` is
started, and pops them off the stack once they are resolved and the queues are
processed.
I also pulled all of the actual queue logic out of `InteractionManager` and into
a new `TaskQueue` class to isolate concerns a bit.
public
Reviewed By: josephsavona
Differential Revision: D2754311
fb-gh-sync-id: bfd6d0c54e6410cb261aa1d2c5024dd91a3959e6
2015-12-24 00:10:39 +00:00
|
|
|
import type {Task} from 'TaskQueue';
|
2015-05-20 23:53:24 +00:00
|
|
|
|
Add yieldy, chained async task support to InteractionManager
Summary:
Default behavior should be unchanged.
If we queue up a bunch of expensive tasks during an interaction, the default
`InteractionManager` behavior would execute them all in one synchronous loop at
the end the JS event loop via one `setImmediate` call, blocking the JS thread
the entire time.
The `setDeadline` addition in this diff enables an option to only execute tasks
until the `eventLoopRunningTime` is hit (added to MessageQueue/BatchedBridge),
allowing the queue execution to be paused if an interaction starts in between
tasks, making the app more responsive.
Additionally, if a task ends up generating a bunch of additional tasks
asynchronously, the previous implementation would execute these new tasks after
already scheduled tasks. This is often fine, but I want it to fully resolve
async tasks and all their dependencies before making progress in the rest of the
queue, so I added support for `type PromiseTask = {gen: () => Promise}` to do
just this. It works by building a stack of queues each time a `PromiseTask` is
started, and pops them off the stack once they are resolved and the queues are
processed.
I also pulled all of the actual queue logic out of `InteractionManager` and into
a new `TaskQueue` class to isolate concerns a bit.
public
Reviewed By: josephsavona
Differential Revision: D2754311
fb-gh-sync-id: bfd6d0c54e6410cb261aa1d2c5024dd91a3959e6
2015-12-24 00:10:39 +00:00
|
|
|
const _emitter = new EventEmitter();
|
2015-03-14 18:42:25 +00:00
|
|
|
|
2016-03-25 02:43:42 +00:00
|
|
|
const DEBUG_DELAY = 0;
|
2016-04-26 20:18:13 +00:00
|
|
|
const DEBUG = false;
|
2016-03-25 02:43:42 +00:00
|
|
|
|
2015-02-20 04:10:52 +00:00
|
|
|
/**
|
|
|
|
* InteractionManager allows long-running work to be scheduled after any
|
|
|
|
* interactions/animations have completed. In particular, this allows JavaScript
|
|
|
|
* animations to run smoothly.
|
|
|
|
*
|
|
|
|
* Applications can schedule tasks to run after interactions with the following:
|
|
|
|
*
|
2015-03-14 18:42:25 +00:00
|
|
|
* ```
|
|
|
|
* InteractionManager.runAfterInteractions(() => {
|
|
|
|
* // ...long-running synchronous task...
|
|
|
|
* });
|
|
|
|
* ```
|
2015-02-20 04:10:52 +00:00
|
|
|
*
|
|
|
|
* Compare this to other scheduling alternatives:
|
2015-03-14 18:42:25 +00:00
|
|
|
*
|
2015-02-20 04:10:52 +00:00
|
|
|
* - requestAnimationFrame(): for code that animates a view over time.
|
|
|
|
* - setImmediate/setTimeout(): run code later, note this may delay animations.
|
|
|
|
* - runAfterInteractions(): run code later, without delaying active animations.
|
|
|
|
*
|
|
|
|
* The touch handling system considers one or more active touches to be an
|
|
|
|
* 'interaction' and will delay `runAfterInteractions()` callbacks until all
|
|
|
|
* touches have ended or been cancelled.
|
|
|
|
*
|
|
|
|
* InteractionManager also allows applications to register animations by
|
|
|
|
* creating an interaction 'handle' on animation start, and clearing it upon
|
|
|
|
* completion:
|
|
|
|
*
|
2015-03-14 18:42:25 +00:00
|
|
|
* ```
|
|
|
|
* var handle = InteractionManager.createInteractionHandle();
|
|
|
|
* // run animation... (`runAfterInteractions` tasks are queued)
|
|
|
|
* // later, on animation completion:
|
|
|
|
* InteractionManager.clearInteractionHandle(handle);
|
|
|
|
* // queued tasks run if all handles were cleared
|
|
|
|
* ```
|
Add yieldy, chained async task support to InteractionManager
Summary:
Default behavior should be unchanged.
If we queue up a bunch of expensive tasks during an interaction, the default
`InteractionManager` behavior would execute them all in one synchronous loop at
the end the JS event loop via one `setImmediate` call, blocking the JS thread
the entire time.
The `setDeadline` addition in this diff enables an option to only execute tasks
until the `eventLoopRunningTime` is hit (added to MessageQueue/BatchedBridge),
allowing the queue execution to be paused if an interaction starts in between
tasks, making the app more responsive.
Additionally, if a task ends up generating a bunch of additional tasks
asynchronously, the previous implementation would execute these new tasks after
already scheduled tasks. This is often fine, but I want it to fully resolve
async tasks and all their dependencies before making progress in the rest of the
queue, so I added support for `type PromiseTask = {gen: () => Promise}` to do
just this. It works by building a stack of queues each time a `PromiseTask` is
started, and pops them off the stack once they are resolved and the queues are
processed.
I also pulled all of the actual queue logic out of `InteractionManager` and into
a new `TaskQueue` class to isolate concerns a bit.
public
Reviewed By: josephsavona
Differential Revision: D2754311
fb-gh-sync-id: bfd6d0c54e6410cb261aa1d2c5024dd91a3959e6
2015-12-24 00:10:39 +00:00
|
|
|
*
|
|
|
|
* `runAfterInteractions` takes either a plain callback function, or a
|
|
|
|
* `PromiseTask` object with a `gen` method that returns a `Promise`. If a
|
|
|
|
* `PromiseTask` is supplied, then it is fully resolved (including asynchronous
|
|
|
|
* dependencies that also schedule more tasks via `runAfterInteractions`) before
|
|
|
|
* starting on the next task that might have been queued up synchronously
|
|
|
|
* earlier.
|
|
|
|
*
|
|
|
|
* By default, queued tasks are executed together in a loop in one
|
|
|
|
* `setImmediate` batch. If `setDeadline` is called with a positive number, then
|
|
|
|
* tasks will only be executed until the deadline (in terms of js event loop run
|
|
|
|
* time) approaches, at which point execution will yield via setTimeout,
|
|
|
|
* allowing events such as touches to start interactions and block queued tasks
|
|
|
|
* from executing, making apps more responsive.
|
2015-02-20 04:10:52 +00:00
|
|
|
*/
|
|
|
|
var InteractionManager = {
|
|
|
|
Events: keyMirror({
|
|
|
|
interactionStart: true,
|
|
|
|
interactionComplete: true,
|
|
|
|
}),
|
|
|
|
|
2015-03-14 18:42:25 +00:00
|
|
|
/**
|
2016-06-09 05:54:19 +00:00
|
|
|
* Schedule a function to run after all interactions have completed. Returns a cancellable
|
|
|
|
* "promise".
|
2015-03-14 18:42:25 +00:00
|
|
|
*/
|
2016-06-09 05:54:19 +00:00
|
|
|
runAfterInteractions(task: ?Task): {then: Function, done: Function, cancel: Function} {
|
|
|
|
const tasks = [];
|
|
|
|
const promise = new Promise(resolve => {
|
Add yieldy, chained async task support to InteractionManager
Summary:
Default behavior should be unchanged.
If we queue up a bunch of expensive tasks during an interaction, the default
`InteractionManager` behavior would execute them all in one synchronous loop at
the end the JS event loop via one `setImmediate` call, blocking the JS thread
the entire time.
The `setDeadline` addition in this diff enables an option to only execute tasks
until the `eventLoopRunningTime` is hit (added to MessageQueue/BatchedBridge),
allowing the queue execution to be paused if an interaction starts in between
tasks, making the app more responsive.
Additionally, if a task ends up generating a bunch of additional tasks
asynchronously, the previous implementation would execute these new tasks after
already scheduled tasks. This is often fine, but I want it to fully resolve
async tasks and all their dependencies before making progress in the rest of the
queue, so I added support for `type PromiseTask = {gen: () => Promise}` to do
just this. It works by building a stack of queues each time a `PromiseTask` is
started, and pops them off the stack once they are resolved and the queues are
processed.
I also pulled all of the actual queue logic out of `InteractionManager` and into
a new `TaskQueue` class to isolate concerns a bit.
public
Reviewed By: josephsavona
Differential Revision: D2754311
fb-gh-sync-id: bfd6d0c54e6410cb261aa1d2c5024dd91a3959e6
2015-12-24 00:10:39 +00:00
|
|
|
_scheduleUpdate();
|
|
|
|
if (task) {
|
2016-06-09 05:54:19 +00:00
|
|
|
tasks.push(task);
|
2015-11-10 04:13:27 +00:00
|
|
|
}
|
2016-06-09 05:54:19 +00:00
|
|
|
tasks.push({run: resolve, name: 'resolve ' + (task && task.name || '?')});
|
|
|
|
_taskQueue.enqueueTasks(tasks);
|
2015-11-10 04:13:27 +00:00
|
|
|
});
|
2016-06-09 05:54:19 +00:00
|
|
|
return {
|
|
|
|
then: promise.then.bind(promise),
|
2016-09-15 22:11:43 +00:00
|
|
|
done: (...args) => {
|
|
|
|
if (promise.done) {
|
2016-09-16 05:35:06 +00:00
|
|
|
return promise.done(...args);
|
2016-09-15 22:11:43 +00:00
|
|
|
} else {
|
|
|
|
console.warn('Tried to call done when not supported by current Promise implementation.');
|
|
|
|
}
|
|
|
|
},
|
2016-06-09 05:54:19 +00:00
|
|
|
cancel: function() {
|
|
|
|
_taskQueue.cancelTasks(tasks);
|
|
|
|
},
|
|
|
|
};
|
2015-03-14 18:42:25 +00:00
|
|
|
},
|
|
|
|
|
2015-02-20 04:10:52 +00:00
|
|
|
/**
|
|
|
|
* Notify manager that an interaction has started.
|
|
|
|
*/
|
2015-05-20 23:53:24 +00:00
|
|
|
createInteractionHandle(): Handle {
|
2016-06-09 05:54:19 +00:00
|
|
|
DEBUG && infoLog('create interaction handle');
|
Add yieldy, chained async task support to InteractionManager
Summary:
Default behavior should be unchanged.
If we queue up a bunch of expensive tasks during an interaction, the default
`InteractionManager` behavior would execute them all in one synchronous loop at
the end the JS event loop via one `setImmediate` call, blocking the JS thread
the entire time.
The `setDeadline` addition in this diff enables an option to only execute tasks
until the `eventLoopRunningTime` is hit (added to MessageQueue/BatchedBridge),
allowing the queue execution to be paused if an interaction starts in between
tasks, making the app more responsive.
Additionally, if a task ends up generating a bunch of additional tasks
asynchronously, the previous implementation would execute these new tasks after
already scheduled tasks. This is often fine, but I want it to fully resolve
async tasks and all their dependencies before making progress in the rest of the
queue, so I added support for `type PromiseTask = {gen: () => Promise}` to do
just this. It works by building a stack of queues each time a `PromiseTask` is
started, and pops them off the stack once they are resolved and the queues are
processed.
I also pulled all of the actual queue logic out of `InteractionManager` and into
a new `TaskQueue` class to isolate concerns a bit.
public
Reviewed By: josephsavona
Differential Revision: D2754311
fb-gh-sync-id: bfd6d0c54e6410cb261aa1d2c5024dd91a3959e6
2015-12-24 00:10:39 +00:00
|
|
|
_scheduleUpdate();
|
2015-02-20 04:10:52 +00:00
|
|
|
var handle = ++_inc;
|
|
|
|
_addInteractionSet.add(handle);
|
|
|
|
return handle;
|
|
|
|
},
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Notify manager that an interaction has completed.
|
|
|
|
*/
|
2015-05-20 23:53:24 +00:00
|
|
|
clearInteractionHandle(handle: Handle) {
|
2016-06-09 05:54:19 +00:00
|
|
|
DEBUG && infoLog('clear interaction handle');
|
2015-02-20 04:10:52 +00:00
|
|
|
invariant(
|
|
|
|
!!handle,
|
|
|
|
'Must provide a handle to clear.'
|
|
|
|
);
|
Add yieldy, chained async task support to InteractionManager
Summary:
Default behavior should be unchanged.
If we queue up a bunch of expensive tasks during an interaction, the default
`InteractionManager` behavior would execute them all in one synchronous loop at
the end the JS event loop via one `setImmediate` call, blocking the JS thread
the entire time.
The `setDeadline` addition in this diff enables an option to only execute tasks
until the `eventLoopRunningTime` is hit (added to MessageQueue/BatchedBridge),
allowing the queue execution to be paused if an interaction starts in between
tasks, making the app more responsive.
Additionally, if a task ends up generating a bunch of additional tasks
asynchronously, the previous implementation would execute these new tasks after
already scheduled tasks. This is often fine, but I want it to fully resolve
async tasks and all their dependencies before making progress in the rest of the
queue, so I added support for `type PromiseTask = {gen: () => Promise}` to do
just this. It works by building a stack of queues each time a `PromiseTask` is
started, and pops them off the stack once they are resolved and the queues are
processed.
I also pulled all of the actual queue logic out of `InteractionManager` and into
a new `TaskQueue` class to isolate concerns a bit.
public
Reviewed By: josephsavona
Differential Revision: D2754311
fb-gh-sync-id: bfd6d0c54e6410cb261aa1d2c5024dd91a3959e6
2015-12-24 00:10:39 +00:00
|
|
|
_scheduleUpdate();
|
2015-02-20 04:10:52 +00:00
|
|
|
_addInteractionSet.delete(handle);
|
|
|
|
_deleteInteractionSet.add(handle);
|
|
|
|
},
|
|
|
|
|
|
|
|
addListener: _emitter.addListener.bind(_emitter),
|
Add yieldy, chained async task support to InteractionManager
Summary:
Default behavior should be unchanged.
If we queue up a bunch of expensive tasks during an interaction, the default
`InteractionManager` behavior would execute them all in one synchronous loop at
the end the JS event loop via one `setImmediate` call, blocking the JS thread
the entire time.
The `setDeadline` addition in this diff enables an option to only execute tasks
until the `eventLoopRunningTime` is hit (added to MessageQueue/BatchedBridge),
allowing the queue execution to be paused if an interaction starts in between
tasks, making the app more responsive.
Additionally, if a task ends up generating a bunch of additional tasks
asynchronously, the previous implementation would execute these new tasks after
already scheduled tasks. This is often fine, but I want it to fully resolve
async tasks and all their dependencies before making progress in the rest of the
queue, so I added support for `type PromiseTask = {gen: () => Promise}` to do
just this. It works by building a stack of queues each time a `PromiseTask` is
started, and pops them off the stack once they are resolved and the queues are
processed.
I also pulled all of the actual queue logic out of `InteractionManager` and into
a new `TaskQueue` class to isolate concerns a bit.
public
Reviewed By: josephsavona
Differential Revision: D2754311
fb-gh-sync-id: bfd6d0c54e6410cb261aa1d2c5024dd91a3959e6
2015-12-24 00:10:39 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* A positive number will use setTimeout to schedule any tasks after the
|
|
|
|
* eventLoopRunningTime hits the deadline value, otherwise all tasks will be
|
|
|
|
* executed in one setImmediate batch (default).
|
|
|
|
*/
|
|
|
|
setDeadline(deadline: number) {
|
|
|
|
_deadline = deadline;
|
|
|
|
},
|
2015-02-20 04:10:52 +00:00
|
|
|
};
|
|
|
|
|
Add yieldy, chained async task support to InteractionManager
Summary:
Default behavior should be unchanged.
If we queue up a bunch of expensive tasks during an interaction, the default
`InteractionManager` behavior would execute them all in one synchronous loop at
the end the JS event loop via one `setImmediate` call, blocking the JS thread
the entire time.
The `setDeadline` addition in this diff enables an option to only execute tasks
until the `eventLoopRunningTime` is hit (added to MessageQueue/BatchedBridge),
allowing the queue execution to be paused if an interaction starts in between
tasks, making the app more responsive.
Additionally, if a task ends up generating a bunch of additional tasks
asynchronously, the previous implementation would execute these new tasks after
already scheduled tasks. This is often fine, but I want it to fully resolve
async tasks and all their dependencies before making progress in the rest of the
queue, so I added support for `type PromiseTask = {gen: () => Promise}` to do
just this. It works by building a stack of queues each time a `PromiseTask` is
started, and pops them off the stack once they are resolved and the queues are
processed.
I also pulled all of the actual queue logic out of `InteractionManager` and into
a new `TaskQueue` class to isolate concerns a bit.
public
Reviewed By: josephsavona
Differential Revision: D2754311
fb-gh-sync-id: bfd6d0c54e6410cb261aa1d2c5024dd91a3959e6
2015-12-24 00:10:39 +00:00
|
|
|
const _interactionSet = new Set();
|
|
|
|
const _addInteractionSet = new Set();
|
|
|
|
const _deleteInteractionSet = new Set();
|
|
|
|
const _taskQueue = new TaskQueue({onMoreTasks: _scheduleUpdate});
|
|
|
|
let _nextUpdateHandle = 0;
|
|
|
|
let _inc = 0;
|
|
|
|
let _deadline = -1;
|
|
|
|
|
2016-08-12 14:23:42 +00:00
|
|
|
declare function setImmediate(callback: any, ...args: Array<any>): number;
|
|
|
|
|
2015-02-20 04:10:52 +00:00
|
|
|
/**
|
|
|
|
* Schedule an asynchronous update to the interaction state.
|
|
|
|
*/
|
Add yieldy, chained async task support to InteractionManager
Summary:
Default behavior should be unchanged.
If we queue up a bunch of expensive tasks during an interaction, the default
`InteractionManager` behavior would execute them all in one synchronous loop at
the end the JS event loop via one `setImmediate` call, blocking the JS thread
the entire time.
The `setDeadline` addition in this diff enables an option to only execute tasks
until the `eventLoopRunningTime` is hit (added to MessageQueue/BatchedBridge),
allowing the queue execution to be paused if an interaction starts in between
tasks, making the app more responsive.
Additionally, if a task ends up generating a bunch of additional tasks
asynchronously, the previous implementation would execute these new tasks after
already scheduled tasks. This is often fine, but I want it to fully resolve
async tasks and all their dependencies before making progress in the rest of the
queue, so I added support for `type PromiseTask = {gen: () => Promise}` to do
just this. It works by building a stack of queues each time a `PromiseTask` is
started, and pops them off the stack once they are resolved and the queues are
processed.
I also pulled all of the actual queue logic out of `InteractionManager` and into
a new `TaskQueue` class to isolate concerns a bit.
public
Reviewed By: josephsavona
Differential Revision: D2754311
fb-gh-sync-id: bfd6d0c54e6410cb261aa1d2c5024dd91a3959e6
2015-12-24 00:10:39 +00:00
|
|
|
function _scheduleUpdate() {
|
2015-02-20 04:10:52 +00:00
|
|
|
if (!_nextUpdateHandle) {
|
Add yieldy, chained async task support to InteractionManager
Summary:
Default behavior should be unchanged.
If we queue up a bunch of expensive tasks during an interaction, the default
`InteractionManager` behavior would execute them all in one synchronous loop at
the end the JS event loop via one `setImmediate` call, blocking the JS thread
the entire time.
The `setDeadline` addition in this diff enables an option to only execute tasks
until the `eventLoopRunningTime` is hit (added to MessageQueue/BatchedBridge),
allowing the queue execution to be paused if an interaction starts in between
tasks, making the app more responsive.
Additionally, if a task ends up generating a bunch of additional tasks
asynchronously, the previous implementation would execute these new tasks after
already scheduled tasks. This is often fine, but I want it to fully resolve
async tasks and all their dependencies before making progress in the rest of the
queue, so I added support for `type PromiseTask = {gen: () => Promise}` to do
just this. It works by building a stack of queues each time a `PromiseTask` is
started, and pops them off the stack once they are resolved and the queues are
processed.
I also pulled all of the actual queue logic out of `InteractionManager` and into
a new `TaskQueue` class to isolate concerns a bit.
public
Reviewed By: josephsavona
Differential Revision: D2754311
fb-gh-sync-id: bfd6d0c54e6410cb261aa1d2c5024dd91a3959e6
2015-12-24 00:10:39 +00:00
|
|
|
if (_deadline > 0) {
|
2016-03-25 02:43:42 +00:00
|
|
|
_nextUpdateHandle = setTimeout(_processUpdate, 0 + DEBUG_DELAY);
|
Add yieldy, chained async task support to InteractionManager
Summary:
Default behavior should be unchanged.
If we queue up a bunch of expensive tasks during an interaction, the default
`InteractionManager` behavior would execute them all in one synchronous loop at
the end the JS event loop via one `setImmediate` call, blocking the JS thread
the entire time.
The `setDeadline` addition in this diff enables an option to only execute tasks
until the `eventLoopRunningTime` is hit (added to MessageQueue/BatchedBridge),
allowing the queue execution to be paused if an interaction starts in between
tasks, making the app more responsive.
Additionally, if a task ends up generating a bunch of additional tasks
asynchronously, the previous implementation would execute these new tasks after
already scheduled tasks. This is often fine, but I want it to fully resolve
async tasks and all their dependencies before making progress in the rest of the
queue, so I added support for `type PromiseTask = {gen: () => Promise}` to do
just this. It works by building a stack of queues each time a `PromiseTask` is
started, and pops them off the stack once they are resolved and the queues are
processed.
I also pulled all of the actual queue logic out of `InteractionManager` and into
a new `TaskQueue` class to isolate concerns a bit.
public
Reviewed By: josephsavona
Differential Revision: D2754311
fb-gh-sync-id: bfd6d0c54e6410cb261aa1d2c5024dd91a3959e6
2015-12-24 00:10:39 +00:00
|
|
|
} else {
|
|
|
|
_nextUpdateHandle = setImmediate(_processUpdate);
|
|
|
|
}
|
2015-02-20 04:10:52 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Notify listeners, process queue, etc
|
|
|
|
*/
|
Add yieldy, chained async task support to InteractionManager
Summary:
Default behavior should be unchanged.
If we queue up a bunch of expensive tasks during an interaction, the default
`InteractionManager` behavior would execute them all in one synchronous loop at
the end the JS event loop via one `setImmediate` call, blocking the JS thread
the entire time.
The `setDeadline` addition in this diff enables an option to only execute tasks
until the `eventLoopRunningTime` is hit (added to MessageQueue/BatchedBridge),
allowing the queue execution to be paused if an interaction starts in between
tasks, making the app more responsive.
Additionally, if a task ends up generating a bunch of additional tasks
asynchronously, the previous implementation would execute these new tasks after
already scheduled tasks. This is often fine, but I want it to fully resolve
async tasks and all their dependencies before making progress in the rest of the
queue, so I added support for `type PromiseTask = {gen: () => Promise}` to do
just this. It works by building a stack of queues each time a `PromiseTask` is
started, and pops them off the stack once they are resolved and the queues are
processed.
I also pulled all of the actual queue logic out of `InteractionManager` and into
a new `TaskQueue` class to isolate concerns a bit.
public
Reviewed By: josephsavona
Differential Revision: D2754311
fb-gh-sync-id: bfd6d0c54e6410cb261aa1d2c5024dd91a3959e6
2015-12-24 00:10:39 +00:00
|
|
|
function _processUpdate() {
|
|
|
|
_nextUpdateHandle = 0;
|
2015-04-13 18:19:28 +00:00
|
|
|
|
2015-02-20 04:10:52 +00:00
|
|
|
var interactionCount = _interactionSet.size;
|
|
|
|
_addInteractionSet.forEach(handle =>
|
|
|
|
_interactionSet.add(handle)
|
|
|
|
);
|
|
|
|
_deleteInteractionSet.forEach(handle =>
|
|
|
|
_interactionSet.delete(handle)
|
|
|
|
);
|
|
|
|
var nextInteractionCount = _interactionSet.size;
|
|
|
|
|
|
|
|
if (interactionCount !== 0 && nextInteractionCount === 0) {
|
|
|
|
// transition from 1+ --> 0 interactions
|
|
|
|
_emitter.emit(InteractionManager.Events.interactionComplete);
|
|
|
|
} else if (interactionCount === 0 && nextInteractionCount !== 0) {
|
|
|
|
// transition from 0 --> 1+ interactions
|
|
|
|
_emitter.emit(InteractionManager.Events.interactionStart);
|
|
|
|
}
|
|
|
|
|
|
|
|
// process the queue regardless of a transition
|
|
|
|
if (nextInteractionCount === 0) {
|
Add yieldy, chained async task support to InteractionManager
Summary:
Default behavior should be unchanged.
If we queue up a bunch of expensive tasks during an interaction, the default
`InteractionManager` behavior would execute them all in one synchronous loop at
the end the JS event loop via one `setImmediate` call, blocking the JS thread
the entire time.
The `setDeadline` addition in this diff enables an option to only execute tasks
until the `eventLoopRunningTime` is hit (added to MessageQueue/BatchedBridge),
allowing the queue execution to be paused if an interaction starts in between
tasks, making the app more responsive.
Additionally, if a task ends up generating a bunch of additional tasks
asynchronously, the previous implementation would execute these new tasks after
already scheduled tasks. This is often fine, but I want it to fully resolve
async tasks and all their dependencies before making progress in the rest of the
queue, so I added support for `type PromiseTask = {gen: () => Promise}` to do
just this. It works by building a stack of queues each time a `PromiseTask` is
started, and pops them off the stack once they are resolved and the queues are
processed.
I also pulled all of the actual queue logic out of `InteractionManager` and into
a new `TaskQueue` class to isolate concerns a bit.
public
Reviewed By: josephsavona
Differential Revision: D2754311
fb-gh-sync-id: bfd6d0c54e6410cb261aa1d2c5024dd91a3959e6
2015-12-24 00:10:39 +00:00
|
|
|
while (_taskQueue.hasTasksToProcess()) {
|
|
|
|
_taskQueue.processNext();
|
|
|
|
if (_deadline > 0 &&
|
|
|
|
BatchedBridge.getEventLoopRunningTime() >= _deadline) {
|
|
|
|
// Hit deadline before processing all tasks, so process more later.
|
|
|
|
_scheduleUpdate();
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2015-02-20 04:10:52 +00:00
|
|
|
}
|
|
|
|
_addInteractionSet.clear();
|
|
|
|
_deleteInteractionSet.clear();
|
|
|
|
}
|
|
|
|
|
|
|
|
module.exports = InteractionManager;
|