Summary:
Just can't get the point. What does `the next task that might have been queued up earlier` mean? Earlier than what? `The first task`? Please correct me if I missed something.
Closes https://github.com/facebook/react-native/pull/4970
Reviewed By: svcscm
Differential Revision: D2789390
Pulled By: sahrens
fb-gh-sync-id: 3078fb6cbc7940d26d2dc393ba9448f132721ea2
Summary:
Rather than specifying what not to mock, turn off autoMock for this test suite, and only mock BatchedBridge.
Fixes#4965
Closes https://github.com/facebook/react-native/pull/4967
Reviewed By: svcscm
Differential Revision: D2789079
Pulled By: androidtrunkagent
fb-gh-sync-id: 0d7024f92b630a3c0643ea2e1fde8d673fcdf6e1
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
Summary: In accordance with the unwritten rule that any API that takes a callback should also return a promise, I've changed `InteractionManager.runAfterInteractions()` to do just that.
```js
InteractionManager.runAfterInteractions(() => {
...
});
```
can become
```js
InteractionManager.runAfterInteractions().then(() => {
...
});
```
(but doesn't have to). Most importantly, though, this change enables code like
```js
doSomeUIStuff();
await InteractionManager.runAfterInteractions();
doSomeNonUIStuff();
```
which is nice.
Note: Because returning a `Promise` means the callback argument is now optional, the behaviour of the API is slightly changed, though not in a backwards-incompatible way (unless a consumer is in some way relying on the exception, but that would be insane).
Closes https://github.com/facebook/react-native/pull/3788
Reviewed By: vjeux
Differential Revision: D2634693
Pulled By: josephsavona
fb-gh-sync-id: 7315120963be23cf69d777e940b2750d32ae47a8
sunnylqm
Adam Miskiewicz
Spencer Ahrens
Philipp von Weitershausen
Joe Savona
Tim Yung
Basil Hosmer
Eric Vicenti
Christopher Chedeau