Summary:
I'm working on deploying haste2 with jest. This updates all the files that require changes for this to work and they are backwards compatible with the current version of jest.
* package.json was just outdated. I think haste1's liberal handling with collisions made this a "non-issue"
* env.js didn't properly set up ErrorUtils, also unsure why that isn't a problem in jest right now already?
* some things were mocking things they shouldn't
* Because of the regex that matches against providesModule and System.import, it isn't possible to list module names more than once. We have multiple tests reusing the same providesModule ids and using System.import with modules that only exist virtually within that test. Splitting up the strings makes the regexes work (we do the same kind of splitting on www sometimes if we need to) and using different providesModule names in different test files fixes the problem. I think the BundlesLayoutIntegration-test is going to be deleted, so this doesn't even matter.
public
Reviewed By: voideanvalue
Differential Revision: D2809681
fb-gh-sync-id: 8fe6ed8b5a1be28ba141e9001de143e502693281
Summary:
public
We should further improve this on the future by showing the actual stacktrace instead of the `HMRClient` one. Also, we need to integrate this with the dev plugin that opens in the default editor the file/line the user clicks on.
Reviewed By: vjeux
Differential Revision: D2798889
fb-gh-sync-id: 2392966908c493e86e11b0d024e7b68156c9066c
Summary:
public
If Hot Loading is enabled bu the packager server is not running, as the user updates files he'll see red boxes caused by the HMR runtime. The error those red boxes show is pretty weird for the end user. Lets improve the feedback we give!.
Reviewed By: vjeux
Differential Revision: D2795534
fb-gh-sync-id: dcc39e6682e0603bf10d0f5e623433262b745660
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
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:
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:
This pull request adds an example to the Dimensions documentations. Specifically, it gives an example of how to get the height and width from the window.
I'm submitting this documentation because discovering this information cost me some time and my hope is to save other folks time by having this info right in the docs generated from the comments in this file.
Let me know if you need anything else.
Closes https://github.com/facebook/react-native/pull/4211
Reviewed By: svcscm
Differential Revision: D2719953
Pulled By: androidtrunkagent
fb-gh-sync-id: 86d18e3847066211a013a50ce2f2a3e2032f5052
Summary:
public
The `DialogModule` requires `android.support.v4.app.FragmentManager` which means
every app that wants to use Dialogs would need to have its Activity extend the legacy
`android.support.v4.app.FragmentActivity`.
This diff makes the `DialogModule` work with both the Support `FragmentManager`
(for AdsManager & potentially other fb apps) and the `android.app.FragmentManager`
(for new apps with no legacy dependencies).
Also wrap the native module in the same `Alert` API that we have on iOS and provide
a cross-platform example. In my opinion the iOS Alert API is quite nice and easy to use.
We still keep `AlertIOS` around because of its `prompt` function which is iOS-specific
and also for backwards compatibility.
Reviewed By: foghina
Differential Revision: D2647000
fb-gh-sync-id: e2280451890bff58bd9c933ab53cd99055403858
Summary:
public
We were adding all the arguments passed to all the JS functions and callbacks
called over the bridge to marker names, and this args can be huge, meaning a lot
of time spent stringifying arguments and therefore less accurate profile results
Reviewed By: nicklockwood
Differential Revision: D2761809
fb-gh-sync-id: 2d0b5b90cc9e59fe491c108b0360b84ab5fee5b7
Summary:
public
Most of the time - especially during app startup - when we call UIManager.manageChildren(), we are actually just adding the first set of children to a newly created view.
This case is already optimized for in the JS code, by memoizing index arrays at various sizes, but this is not especially efficient since it is still sending an array of indices with each call that could be easily inferred on the native side instead.
I've added a hybrid native/JS optimization that improves the performance for this case. It's not a huge win in terms of time saved, but benchmarks show improvements in the ~1% range for several of the app startup metrics.
Reviewed By: tadeuzagallo
Differential Revision: D2757388
fb-gh-sync-id: 74f0cdbba93af2c04d69b192a8c2cc5cf429fa09
Summary:
public
Rename the `BridgeProfiling` JS module to `Systrace`, since it's actually just
an API to Systrace markers.
This should make it clearer as we add more perf tooling.
Reviewed By: jspahrsummers
Differential Revision: D2734001
fb-gh-sync-id: 642848fa7340c545067f2a7cf5cef8af1c8a69a2
Summary:
MessageQueue no longer falls back to require. To do this we need to register all the modules in our internal unit tests. I did this codemod manually.
This is a bit unfortunate boilerplate but there are very few of these modules outside of unit tests. This boilerplate is only a hassle for these test files.
public
Reviewed By: spicyj
Differential Revision: D2736397
fb-gh-sync-id: 59fa4c4e75c538f3577bc9693b93e1b7c4d4d233
Summary:
The JavaScript ecosystem doesn't have the notion of a built-in native module loader. Even Node is decoupled from its module loader. The module loader system is just JS that runs on top of the global `process` object which has all the built-in goodies.
Additionally there is no such thing as a global require. That is something unique to our providesModule system. In other module systems such as node, every require is contextual. Even registered npm names are localized by version.
The only global namespace that is accessible to the host environment is the global object. Normally module systems attaches itself onto the hooks provided by the host environment on the global object.
Currently, we have two forms of dispatch that reaches directly into the module system. executeJSCall which reaches directly into require. Everything now calls through the BatchedBridge module (except one RCTLog edge case that I will fix). I propose that the executors calls directly onto `BatchedBridge` through an instance on the global so that everything is guaranteed to go through it. It becomes the main communication hub.
I also propose that we drop the dynamic requires inside of MessageQueue/BatchBridge and instead have the modules register themselves with the bridge.
executeJSCall was originally modeled after the XHP equivalent. The XHP equivalent was designed that way because the act of doing the call was the thing that defined a dependency on the module from the page. However, that is not how React Native works.
The JS side is driving the dependencies by virtue of requiring new modules and frameworks and the existence of dependencies is driven by the JS side, so this design doesn't make as much sense.
The main driver for this is to be able to introduce a new module system like Prepack's module system. However, it also unlocks the possibility to do dead module elimination even in our current module system. It is currently not possible because we don't know which module might be called from native.
Since the module system now becomes decoupled we could publish all our providesModule modules as npm/CommonJS modules using a rewrite script. That's what React Core does.
That way people could use any CommonJS bundler such as Webpack, Closure Compiler, Rollup or some new innovation to create a JS bundle.
This diff expands the executeJSCalls to the BatchedBridge's three individual pieces to make them first class instead of being dynamic. This removes one layer of abstraction. Hopefully we can also remove more of the things that register themselves with the BatchedBridge (various EventEmitters) and instead have everything go through the public protocol. ReactMethod/RCT_EXPORT_METHOD.
public
Reviewed By: vjeux
Differential Revision: D2717535
fb-gh-sync-id: 70114f05483124f5ac5c4570422bb91a60a727f6
Summary: Request from issue #3893
* Added support for `secure-text` and `login-password` types to AlertIOS.
* Fixed and extended the cancel button highlighting functionality, which was broken at some point
* Added localization for default `OK` and `Cancel` labels when using UIAlertController
Closes https://github.com/facebook/react-native/pull/4401
Reviewed By: javache
Differential Revision: D2702052
Pulled By: nicklockwood
fb-gh-sync-id: cce312d7fec949f5fd2a7c656e65c657c4832c8f
Summary: I have disected lint warnings fixes to several PRs. This one fixes lint warnings under Libraries/Utility path.
Closes https://github.com/facebook/react-native/pull/4444
Reviewed By: svcscm
Differential Revision: D2705303
Pulled By: spicyj
fb-gh-sync-id: c745ac62cbff30d6bb9478a1d2465fe56b305f0c
Summary: public
RCTUIManager is a public module with several useful methods, however, unlike most such modules, it does not have a JS wrapper that would allow it to be required directly.
Besides making it more cumbersome to use, this also makes it impossible to modify the UIManager API, or smooth over differences between platforms in the JS layer without breaking all of the call sites.
This diff adds a simple JS wrapper file for the UIManager module to make it easier to work with.
Reviewed By: tadeuzagallo
Differential Revision: D2700348
fb-gh-sync-id: dd9030eface100b1baf756da11bae355dc0f266f
Summary: This code generation executes eagerly and these functions are fairly large and takes time to compile.
However, I'm mostly doing this change because it significantly increases the Prepack binary file size.
In theory, there might be a slight impact on the first use of these interpolators but I couldn't really tell.
An alternative would be to create a factory that is called by the components at an appropriate time, or to just refactor the whole thing to use Animated.
I didn't want to dig too deeply for a single component though.
public
Reviewed By: vjeux
Differential Revision: D2687296
fb-gh-sync-id: 6fc8cdf54dfb6f0b50c11db973d67d114bbc7400
Summary: public Add measure() family of methods which allow to easily swizzle methods for profiling
Reviewed By: tadeuzagallo
Differential Revision: D2679904
fb-gh-sync-id: 3724440e1bdaca9e854f4d4124a897a204966dc7
Summary: public
Dynamically profile events from RelayProfiler if available. This will expose time spent in Relay in the systraces.
Reviewed By: tadeuzagallo
Differential Revision: D2674215
fb-gh-sync-id: d5f9d529b86d267a80b0cda2223f6a28a08ac385
Summary: public
We were calling constantsToExport twice for every ViewManager, and including two copies of the values in __fbBatchedBridgeConfig. This diff removes the copy from UIManager and then puts it back on the JS side.
Reviewed By: tadeuzagallo
Differential Revision: D2665625
fb-gh-sync-id: 147ec4bfb404835e3875964476ba233d619c28aa
Summary: public
After reloading the JS side of the profiler wasn't being reenabled.
Reviewed By: javache
Differential Revision: D2602258
fb-gh-sync-id: 5de8afb829e9fa8225600e2b0ff9e00313ac1d4c
Summary: public
Call the native bindings explicitly from BridgeProfiling instead of polyfill'ing `console.profile` with
a function that has a different signature.
Reviewed By: vjeux
Differential Revision: D2602313
fb-gh-sync-id: 9295eff9458f2caa35b7e982c0f7c06dbe65fd09
Summary: public
Use arrays instead of dictionaries for encoding module method information.
This further reduces UIExplorer startup JSON from 16104 bytes to 14119 (12% reduction)
Reviewed By: javache
Differential Revision: D2570057
fb-gh-sync-id: 4a53a9ead4365a136e7caeb650375733e1c24c0e
Summary: public
We're sending a lot of module config data when the app first starts, and much of this is redundant.
UIExplorer current sends 19061 bytes of module config JSON. This diff reduces that to 16104 (15% saving) by stripping modules that have no methods or constants, and removing method types unless method is async.
Reviewed By: tadeuzagallo, javache
Differential Revision: D2570010
fb-gh-sync-id: 8c0abbd1cdee3264b37a4f52e852008caaffb9c5
Christoph Pojer
Martín Bigio
Mike Armstrong
Spencer Ahrens
Calvin Freitas
Christopher Chedeau
Martin Konicek
Martin Konicek
Tadeu Zagallo
Justas Brazauskas
Nick Lockwood
Jan Kassens
Sebastian Markbage
Felipe Martim
Gabe Levi
Christopher Dro
Huang Yu
Alexey Lang
Milen Dzhumerov
Tim Yung
Pieter De Baets
David Aurelio
Andy Street