Commit Graph

5 Commits

Author SHA1 Message Date
David Aurelio ad8a335864 Remove knowledge of fbjs from the packager
Summary:Follow-up to https://github.com/facebook/react-native/pull/5084

This…
- changes all requires within RN to `require('fbjs/lib/…')`
- updates `.flowconfig`
- updates `packager/blacklist.js`
- adapts tests
- removes things from `Libraries/vendor/{core,emitter}` that are also in fbjs
- removes knowledge of `fbjs` from the packager

Closes https://github.com/facebook/react-native/pull/5084

Reviewed By: bestander

Differential Revision: D2926835

fb-gh-sync-id: 2095e22b2f38e032599d1f2601722b3560e8b6e9
shipit-source-id: 2095e22b2f38e032599d1f2601722b3560e8b6e9
2016-03-02 04:28:38 -08:00
Adam Miskiewicz 28116ec3db Reverted commit D2803288
Summary:
As spicyj mentioned in commit 6a838a4, the ideal state of affairs when it comes to consuming `react` and `fbjs` from NPM is for the packager not to have knowledge of either package. This PR addresses the `fbjs` part of that, and relies on https://github.com/facebook/fbjs/pull/95. **DO NOT MERGE** until #95 (or a variation) is in `fbjs` and is released to npm.

This PR does several things:

1. Adds stub modules within RN that expose `fbjs` modules to be required using Haste. After discussing a few ideas with spicyj, this seemed like a good option to keep internal FB devs happy (and not make them change the way they write JS), but allow for removing packager complexity and fit in better with the NPM ecosystem. Note -- it skips stubbing `fetch`, `ExecutionEnvironment`, and `ErrorUtils`, due to the fact that these need to have Native specific implementations, and there's no reason for those implementations to exist in `fbjs`.
2. Removes the modules that were previously being used in lieu of their `fbjs` eq
Closes https://github.com/facebook/react-native/pull/5084

Reviewed By: bestander

Differential Revision: D2803288

Pulled By: javache

fb-gh-sync-id: 121ae811ce4cc30e6ea79246f85a1e4f65648ce1
shipit-source-id: 121ae811ce4cc30e6ea79246f85a1e4f65648ce1
2016-02-11 02:45:34 -08:00
Adam Miskiewicz 98e5e2b427 Remove knowledge of fbjs from the packager
Summary:
As spicyj mentioned in commit 6a838a4, the ideal state of affairs when it comes to consuming `react` and `fbjs` from NPM is for the packager not to have knowledge of either package. This PR addresses the `fbjs` part of that, and relies on https://github.com/facebook/fbjs/pull/95. **DO NOT MERGE** until #95 (or a variation) is in `fbjs` and is released to npm.

This PR does several things:

1. Adds stub modules within RN that expose `fbjs` modules to be required using Haste. After discussing a few ideas with spicyj, this seemed like a good option to keep internal FB devs happy (and not make them change the way they write JS), but allow for removing packager complexity and fit in better with the NPM ecosystem. Note -- it skips stubbing `fetch`, `ExecutionEnvironment`, and `ErrorUtils`, due to the fact that these need to have Native specific implementations, and there's no reason for those implementations to exist in `fbjs`.
2. Removes the modules that were previously being used in lieu of their `fbjs` eq
Closes https://github.com/facebook/react-native/pull/5084

Reviewed By: bestander

Differential Revision: D2803288

Pulled By: davidaurelio

fb-gh-sync-id: fd257958ee2f8696eebe9048c1e7628c168bf4a2
shipit-source-id: fd257958ee2f8696eebe9048c1e7628c168bf4a2
2016-02-11 02:21:37 -08:00
Adam Miskiewicz c972cce405 Fix InteractionManager-test.js
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
2015-12-24 09:25:19 -08:00
Spencer Ahrens 893a54d0cd 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-23 16:12:30 -08:00