Summary:
public
Until we support this fature on OSS, don't show the menu option.
Reviewed By: vjeux
Differential Revision: D2791198
fb-gh-sync-id: 11b66d467c1ab784bbf549b893d0a3abd69e2741
Summary:
public
Implement all the necessary glue code for several diffs submitted before to get Hot Loading work end to end:
- Simplify `HMRClient`: we don't need to make it stateful allowing to enable and disable it because both when we enable and disable the interface we need to reload the bundle.
- On the native side we introduced a singleton to process the bundle URL. This new class might alter the url to include the `hot` attribute. I'm not 100% sure this is the best way to implement this but we cannot use `CTLSettings` for this as it's are not available on oss and I didn't want to contaminate `RCTBridge` with something specific to hot loading. Also, we could potentially use this processor for other things in the future. Please let me know if you don't like this approach or you have a better idea :).
- Use this processor to alter the default bundle URL and request a `hot` bundle when hot loading is enabled. Also make sure to enable the HMR interface when the client activates it on the dev menu.
- Add packager `hot` option.
- Include gaeron's `react-transform` on Facebook's JS transformer.
The current implementation couples a bit React Native to this feature because `react-transform-hmr` is required on `InitializeJavaScriptAppEngine`. Ideally, the packager should accept an additional list of requires and include them on the bundle among all their dependencies. Note this is not the same as the option `runBeforeMainModule` as that one only adds a require to the provided module but doesn't include all the dependencies that module amy have that the entry point doesn't. I'll address this in a follow up task to enable asap hot loading (9536142)
I had to remove 2 `.babelrc` files from `react-proxy` and `react-deep-force-update`. There's an internal task for fixing the underlaying issue to avoid doing this horrible hack (t9515889).
Reviewed By: vjeux
Differential Revision: D2790806
fb-gh-sync-id: d4b78a2acfa071d6b3accc2e6716ef5611ad4fda
Summary:
public
Add a very simple runtime for self-accepting modules. The API is the same one as Webpacks's one for now.
The new infra will be end-to-end tested on a follow up diff.
Reviewed By: vjeux
Differential Revision: D2789428
fb-gh-sync-id: c39524814d53c6e4ec9d9d011081ea81089b00b6
Summary:
public
This diff adds infra to both the Packager and the running app to have a WebSocket based connection between them. This connection is toggled by a new dev menu item, namely `Enable/Disable Hot Loading`.
Reviewed By: vjeux
Differential Revision: D2787621
fb-gh-sync-id: d1dee769348e4830c28782e7b650d025f2b3a786
Summary:
public
The Whole Program Optimisation (WPO) pass is quite slow, and can make it painful
to iterate when having `dev=false`. Move it to happen only when both `dev=false` and `minify=true`.
Reviewed By: davidaurelio
Differential Revision: D2773941
fb-gh-sync-id: ac5ca4e1286e233c2d175eecdbf7494d5d3497b2
Using the provided WebSocket example under react-native 0.17, the sample code throws the following error:
"TypeError: ws.on is not a function(…)"
It's listening on ".on" which does not exist, rather than assigning a function to onopen, onmessage, onerror and onclose.
See: https://developer.mozilla.org/en-US/docs/Web/API/WebSocket
Summary:
I don't know the reasons, why the templates are written with the `react.createClass`method. Today I see lot's of examples using the **ES6 way**. In my own projects I'm using this way, too.
I removed `use strict`, since *Module code is always strict mode code*, according to the [spec](http://www.ecma-international.org/ecma-262/6.0/#sec-strict-mode-code).
Maybe we should **discuss** the usage of ES6 in the templates.
Closes https://github.com/facebook/react-native/pull/4891
Reviewed By: svcscm
Differential Revision: D2789493
Pulled By: androidtrunkagent
fb-gh-sync-id: 90e70f787017c61dc64cbc9f0beb02331fa749ec
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:
There's quite a bit of code scattered around the packager regarding ignoring the `providesModule` Haste pragma in any file that isn't in `react-native`, `react-tools` or `parse`. There is even a (passing) test case.
However, there's an edge case.
Take, for example, `fbjs`. It has a module inside of it called `ErrorUtils`. `react-relay` requires this file normally, in Common.JS style, by doing `require('fbjs/libs/ErrorUtils')`. But when `react-native` attempts to require `ErrorUtils` using the HasteModule format (in it's JavaScript initialization), it resolves the `fbjs` `ErrorUtils` module, instead of RN's `ErrorUtils`.
This happens, it turns out, because when a module is read (in `Module._read`), it's not caring about whether or not it should pay attention to `providesModule`, and is just assigning the `providesModule` value as the id of the module no matter what. Then when `Module.getName` is called, it will always use that `data.id` that was set, thus creating the wrong dependency tree.
This
Closes https://github.com/facebook/react-native/pull/3625
Reviewed By: svcscm
Differential Revision: D2632317
Pulled By: vjeux
fb-gh-sync-id: efd8066eaf6f18fcf79698beab36cab90bf5cd6d
Summary:
Passing around a `getTransformOptions` function doesn't really work with the CLI utils, so I'm changing this to `getTransformOptionsModulePath` instead, which can easily be injected in through `rn-cli.config.js`.
public
Reviewed By: martinbigio
Differential Revision: D2785789
fb-gh-sync-id: c9fdc358cb5d0db27e0d02496e44c013c77f3d5f
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:
Problem: https://github.com/facebook/react-native/issues/4708
Solution: Added a ColorPropType that validates the color used by the dev
Notes:
1) I'm working a Win8.1 machine and couldn't build the react-native using the github repo. As soon as I figure that out, I'll probably figure how to run the tests and how to add some for this feature.
2) It's my first pull request. Be gentle :)
Closes https://github.com/facebook/react-native/pull/4866
Reviewed By: bestander, svcscm
Differential Revision: D2783672
Pulled By: nicklockwood
fb-gh-sync-id: ca22aa3c0999188075681b5d20fff0631496e238
Summary:
This PR adds a contentInsetStart and a contentInsetEnd property to ToolbarAndroid, allowing offsetting Toolbar contents to different keylines
Closes https://github.com/facebook/react-native/pull/4699
Reviewed By: svcscm
Differential Revision: D2759294
Pulled By: mkonicek
fb-gh-sync-id: f22aa255f07929ad7a99ac7568981d35e848065b
Summary:
Here are some small fixes for issues we've encountered with very large RN projects (mostly huge dependency trees in `node_modules`).
cc amasad martinbigio
Closes https://github.com/facebook/react-native/pull/4880
Reviewed By: svcscm
Differential Revision: D2782834
Pulled By: mkonicek
fb-gh-sync-id: e316a62b84ba796b80ac819431414ebf27f7b566
Summary:
This PR makes the android dev menu consistent with iOS where toggling the inspector will update the button label accordingly.
Closes https://github.com/facebook/react-native/pull/4628
Reviewed By: svcscm
Differential Revision: D2740549
Pulled By: mkonicek
fb-gh-sync-id: 02458d09b84e1592dcf245290ee2bbfb2863060d
Summary:
public React allows excluding certain elements from touch handling by assigning `PointerEvents` filter to them, such as BOX_NONE - this element will not receive touch but its children will, BOX_ONLY - only this element will receive pointer event and not children, NONE - neither this element nor its children will receive pointer events, and AUTO - pointer events are allowed for both this element and its children.
This diff adds PointerEvents support to flat RCTView. Most of the implementation is copied from ReactViewManager/ReactViewGroup. One small change is made to TouchTargetHelper to ensure that it works correctly with virtual nodes when their parent has PointerEvents set to PointerEvents.BOX_NONE.
Reviewed By: ahmedre
Differential Revision: D2784208
fb-gh-sync-id: 4b831f9b1bfb8014a99d7b33534ae7ff7b4ab498
Summary:
public
Added JS wrappers for ImageStore(Manager) and ImageEditor(Manager) so they can be required in the normal way instead of accessed directly via NativeModules.
Reviewed By: dmmiller
Differential Revision: D2773822
fb-gh-sync-id: 6eeafd3f80a87b1b91a04a2aebad6e2fd31b0e98
Summary:
It wasn't in UIExplorerList.ios.js (only in UIExplorerList.js) so it was not being pulled in on the iOS UIExplorer.
Closes https://github.com/facebook/react-native/pull/2196
Reviewed By: majak
Differential Revision: D2780150
Pulled By: nicklockwood
fb-gh-sync-id: f111ec6e29465c4c7f22ca8faec8fc17a96a80cb
Brent Vatne
Martín Bigio
Christopher Chedeau
Noah Jorgenson
sunnylqm
Satyajit Sahoo
Tadeu Zagallo
Hosain
Patrick Puritscher
SangYeob Bono Yu
Wesley Ellis
Konstantin Raev
Adam Miskiewicz
Max
Bhuwan Khattar
Spencer Ahrens
Martin Konicek
James Ide
toomass
Pieter De Baets
Janic Duplessis
StefanT
Andreas Stütz
Mike Fowler
Philipp von Weitershausen
Christopher Dro
Denis Koroskin
Nick Lockwood
Christoph Pojer
