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
|
|
|
/**
|
2016-06-09 05:54:19 +00:00
|
|
|
* Copyright (c) 2013-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.
|
|
|
|
*
|
2017-11-02 13:14:11 +00:00
|
|
|
* @emails oncall+react_native
|
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
|
|
|
*/
|
|
|
|
|
|
|
|
'use strict';
|
|
|
|
|
2017-06-14 19:44:05 +00:00
|
|
|
const Promise = require('promise');
|
|
|
|
|
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 expectToBeCalledOnce(fn) {
|
|
|
|
expect(fn.mock.calls.length).toBe(1);
|
|
|
|
}
|
|
|
|
|
|
|
|
function clearTaskQueue(taskQueue) {
|
|
|
|
do {
|
|
|
|
jest.runAllTimers();
|
|
|
|
taskQueue.processNext();
|
|
|
|
jest.runAllTimers();
|
2016-06-09 05:54:19 +00:00
|
|
|
} while (taskQueue.hasTasksToProcess());
|
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
|
|
|
}
|
|
|
|
|
|
|
|
describe('TaskQueue', () => {
|
|
|
|
let taskQueue;
|
|
|
|
let onMoreTasks;
|
|
|
|
let sequenceId;
|
|
|
|
function createSequenceTask(expectedSequenceId) {
|
2016-04-28 02:15:28 +00:00
|
|
|
return jest.fn(() => {
|
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
|
|
|
expect(++sequenceId).toBe(expectedSequenceId);
|
|
|
|
});
|
|
|
|
}
|
|
|
|
beforeEach(() => {
|
2016-12-19 01:02:57 +00:00
|
|
|
jest.resetModules();
|
2016-04-28 02:15:28 +00:00
|
|
|
onMoreTasks = jest.fn();
|
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 TaskQueue = require('TaskQueue');
|
|
|
|
taskQueue = new TaskQueue({onMoreTasks});
|
|
|
|
sequenceId = 0;
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
|
|
it('should run a basic task', () => {
|
|
|
|
const task1 = createSequenceTask(1);
|
|
|
|
taskQueue.enqueue({run: task1, name: 'run1'});
|
|
|
|
expect(taskQueue.hasTasksToProcess()).toBe(true);
|
|
|
|
taskQueue.processNext();
|
|
|
|
expectToBeCalledOnce(task1);
|
|
|
|
});
|
|
|
|
|
|
|
|
it('should handle blocking promise task', () => {
|
2016-04-28 02:15:28 +00:00
|
|
|
const task1 = jest.fn(() => {
|
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
|
|
|
return new Promise(resolve => {
|
|
|
|
setTimeout(() => {
|
|
|
|
expect(++sequenceId).toBe(1);
|
|
|
|
resolve();
|
|
|
|
}, 1);
|
|
|
|
});
|
|
|
|
});
|
|
|
|
const task2 = createSequenceTask(2);
|
|
|
|
taskQueue.enqueue({gen: task1, name: 'gen1'});
|
|
|
|
taskQueue.enqueue({run: task2, name: 'run2'});
|
|
|
|
|
|
|
|
taskQueue.processNext();
|
|
|
|
|
|
|
|
expectToBeCalledOnce(task1);
|
|
|
|
expect(task2).not.toBeCalled();
|
|
|
|
expect(onMoreTasks).not.toBeCalled();
|
|
|
|
expect(taskQueue.hasTasksToProcess()).toBe(false);
|
|
|
|
|
|
|
|
clearTaskQueue(taskQueue);
|
|
|
|
|
|
|
|
expectToBeCalledOnce(onMoreTasks);
|
|
|
|
expectToBeCalledOnce(task2);
|
|
|
|
});
|
|
|
|
|
|
|
|
it('should handle nested simple tasks', () => {
|
2016-04-28 02:15:28 +00:00
|
|
|
const task1 = jest.fn(() => {
|
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
|
|
|
expect(++sequenceId).toBe(1);
|
|
|
|
taskQueue.enqueue({run: task3, name: 'run3'});
|
|
|
|
});
|
|
|
|
const task2 = createSequenceTask(2);
|
|
|
|
const task3 = createSequenceTask(3);
|
|
|
|
taskQueue.enqueue({run: task1, name: 'run1'});
|
|
|
|
taskQueue.enqueue({run: task2, name: 'run2'}); // not blocked by task 1
|
|
|
|
|
|
|
|
clearTaskQueue(taskQueue);
|
|
|
|
|
|
|
|
expectToBeCalledOnce(task1);
|
|
|
|
expectToBeCalledOnce(task2);
|
|
|
|
expectToBeCalledOnce(task3);
|
|
|
|
});
|
|
|
|
|
|
|
|
it('should handle nested promises', () => {
|
2016-04-28 02:15:28 +00:00
|
|
|
const task1 = jest.fn(() => {
|
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
|
|
|
return new Promise(resolve => {
|
|
|
|
setTimeout(() => {
|
|
|
|
expect(++sequenceId).toBe(1);
|
|
|
|
taskQueue.enqueue({gen: task2, name: 'gen2'});
|
|
|
|
taskQueue.enqueue({run: resolve, name: 'resolve1'});
|
|
|
|
}, 1);
|
|
|
|
});
|
|
|
|
});
|
2016-04-28 02:15:28 +00:00
|
|
|
const task2 = jest.fn(() => {
|
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
|
|
|
return new Promise(resolve => {
|
|
|
|
setTimeout(() => {
|
|
|
|
expect(++sequenceId).toBe(2);
|
|
|
|
taskQueue.enqueue({run: task3, name: 'run3'});
|
|
|
|
taskQueue.enqueue({run: resolve, name: 'resolve2'});
|
|
|
|
}, 1);
|
|
|
|
});
|
|
|
|
});
|
|
|
|
const task3 = createSequenceTask(3);
|
|
|
|
const task4 = createSequenceTask(4);
|
|
|
|
taskQueue.enqueue({gen: task1, name: 'gen1'});
|
|
|
|
taskQueue.enqueue({run: task4, name: 'run4'}); // blocked by task 1 promise
|
|
|
|
|
|
|
|
clearTaskQueue(taskQueue);
|
|
|
|
|
|
|
|
expectToBeCalledOnce(task1);
|
|
|
|
expectToBeCalledOnce(task2);
|
|
|
|
expectToBeCalledOnce(task3);
|
|
|
|
expectToBeCalledOnce(task4);
|
|
|
|
});
|
2016-06-09 05:54:19 +00:00
|
|
|
|
|
|
|
it('should be able to cancel tasks', () => {
|
|
|
|
const task1 = jest.fn();
|
|
|
|
const task2 = createSequenceTask(1);
|
|
|
|
const task3 = jest.fn();
|
|
|
|
const task4 = createSequenceTask(2);
|
|
|
|
taskQueue.enqueue(task1);
|
|
|
|
taskQueue.enqueue(task2);
|
|
|
|
taskQueue.enqueue(task3);
|
|
|
|
taskQueue.enqueue(task4);
|
|
|
|
taskQueue.cancelTasks([task1, task3]);
|
|
|
|
clearTaskQueue(taskQueue);
|
|
|
|
expect(task1).not.toBeCalled();
|
|
|
|
expect(task3).not.toBeCalled();
|
|
|
|
expectToBeCalledOnce(task2);
|
|
|
|
expectToBeCalledOnce(task4);
|
|
|
|
expect(taskQueue.hasTasksToProcess()).toBe(false);
|
|
|
|
});
|
2016-07-11 23:06:42 +00:00
|
|
|
|
|
|
|
it('should not crash when last task is cancelled', () => {
|
|
|
|
const task1 = jest.fn();
|
|
|
|
taskQueue.enqueue(task1);
|
|
|
|
taskQueue.cancelTasks([task1]);
|
|
|
|
clearTaskQueue(taskQueue);
|
|
|
|
expect(task1).not.toBeCalled();
|
|
|
|
expect(taskQueue.hasTasksToProcess()).toBe(false);
|
|
|
|
});
|
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
|
|
|
});
|