Summary: Developer tools have a lot of dependencies on the bridge, so for now I'm just disabling them in bridgeless mode entirely by guarding everything in `setUpDeveloperTools` with the `RN$Bridgeless` flag. Also consolidating some of the stuff Dan added to `InitializeCore` for hot reloading in here.
Reviewed By: zackargyle
Differential Revision: D15797924
fbshipit-source-id: 360ea81a2844e49f7281eed259fc16a541148ac2
Summary:
This is the same diff as D14786123 but with one of the buck targets fixed that only failed on continuous and didn't run during land time.
This moves Map/Set to fb internal. We do not need them in open source any more but we still need this in some apps at FB that use an old version of JSC.
Reviewed By: rickhanlonii
Differential Revision: D15713305
fbshipit-source-id: caec43c76a6255b2af1693c13d8dea31d7d674f5
Summary:
Hot reloading propagates upwards through the inverse dependency tree — from a file you edited, to the files that import it, and so on. However, we can't always reevaluate everything. Many core infra modules can't run twice, and also the more you run, the more the risk of encountering a module with init side effects. So our practical compromise is to stop the propagation when we reach a module whose exports look like React components. We say that such module "accepts" an update. This means that in practice, changes trigger module reevaluation up to the closest component modules from the edited file. (If you edited a component file, it re-executes alone — unless it exports a non-component.)
However, current implementation has a problem. Sometimes there is an inverse dependency path that has no "accepting" modules whatsoever. For example, maybe you're editing some core module, and its inverse dependency tree reaches goes into React Native itself. Or maybe it reaches the entry point with a bunch of side effects that can't be repeated, like registering the app root component.
In the past, such cases would lead to confusing errors like "Expected `FBPrelude.conclude()` to have been called" after hot reload. This was because we kept re-executing modules all the way upwards, even if there is nothing that can accept the update on the path. Eventually we'd reach top-level modules in the import graph that don't like to run twice.
This diff changes the logic so that we *don't attempt* to re-execute the module factories if we know that some inverse dependency path doesn't terminate in a component. In that case we know we simply *can't apply the hot update* because it doesn't stop at a point we can handle, like a React component.
Since the hot update fails in this case, I'm making it fall back to a regular reload. This is similar to how webpack handles a similar situation on the web. This means that hot updates normally don't refresh, but if we can't apply a hot update to this file, we do refresh automatically.
Reviewed By: cpojer
Differential Revision: D15631864
fbshipit-source-id: 52cd1b03739fd760f1b1b1ab8c7276a150cc3c4c
Summary: This moves Map/Set to fb internal. We do not need them in open source any more but we still need this in some apps at FB that use an old version of JSC.
Reviewed By: TheSavior
Differential Revision: D14786123
fbshipit-source-id: 1c49b47d547ad30f2d93c00b44382cf410100b67
Summary: This check isn't needed in prod as the bundle is served with the app. In dev mode it's possible to have native and JS out of sync.
Reviewed By: yungsters
Differential Revision: D15268485
fbshipit-source-id: 9aeeb6cf5ca91baa90b85e18c848c3b10d85b0f7
Summary:
This is the next step in moving RN towards standard path-based requires. All the requires in `Libraries` have been rewritten to use relative requires with a few exceptions, namely, `vendor` and `Renderer/oss` since those need to be changed upstream. This commit uses relative requires instead of `react-native/...` so that if Facebook were to stop syncing out certain folders and therefore remove code from the react-native package, internal code at Facebook would not need to change.
See the umbrella issue at https://github.com/facebook/react-native/issues/24316 for more detail.
[General] [Changed] - Migrate "Libraries" from Haste to standard path-based requires
Pull Request resolved: https://github.com/facebook/react-native/pull/24749
Differential Revision: D15258017
Pulled By: cpojer
fbshipit-source-id: a1f480ea36c05c659b6f37c8f02f6f9216d5a323
Summary: This is the first diff in an effort to remove Geolocation from React Native. This diff removes the globally injected navigator.geolocation feature and instead requires explicit importing of `Geolocation`. When using Web APIs, people will need to patch `navigator.geolocation` on their own from now on.
Reviewed By: sahrens
Differential Revision: D14692386
fbshipit-source-id: c57b290b49728101250d726d67b1956ff23a9a92
Summary:
I'm changing all callsites to use either global or scoped perf logger explicitly in one diff.
`GlobalPerformanceLogger` is basically a singleton
`scopedPerformanceLogger` is scoped to the React tree by using a React Context
Reviewed By: sahrens
Differential Revision: D14186694
fbshipit-source-id: 062c76eea8fce9d9b531f0eddf153bb79d52f68d
Summary: It seems like `nativePerformanceNow` might not be getting installed in time to be used by InitializeCore on Android. Using PerformanceLogger.currentTimestamp instead, which uses nativeQPLTimestamp (which is what we should be using anyway)
Reviewed By: alexeylang
Differential Revision: D12875187
fbshipit-source-id: 6eda5d2ed7948ba48c63f76b40b2014511c32494
Summary: Split up InitializeCore into a bunch of modules. The idea here is to make it easier for apps to just get the initialization logic they want and leave behind what they don't; for example, if you don't want the Map/Set polyfills, instead of requiring InitializeCore you can require the modules you want from it.
Reviewed By: yungsters
Differential Revision: D10842564
fbshipit-source-id: 3b12d54fddea8c4ee75886022338c214987a015c
Summary: Instead of having a single point at the top of InitializeCore, let's just create a subspan for it. Initially I just wanted to use this point to track JS start time, but it'll be useful to see how long initializeCore takes, too.
Reviewed By: alexeylang
Differential Revision: D10521595
fbshipit-source-id: 3025c34ffab39b79efc966f0c0eb6f502c91c550
Summary: Adding perf marker point to the beginning of InitializeCore.
Reviewed By: TheSavior
Differential Revision: D10496350
fbshipit-source-id: 56c77414e0c31cf918377e95e3b0c236a5672e35
Summary:
This diff fixes an issue that caused the problem with `regeneratorRuntime` last Friday (more info: https://fb.facebook.com/groups/frontendsupport/permalink/2427883350560427/).
The root issue is that both `InitializeCore` and `FBInitializeCore` are included in the same bundle, this fix just prevents the bundle from being invalid once this happens..
*copied from: https://our.intern.facebook.com/intern/diff/D10444264/?transaction_id=595485237532887*
The way that `regeneratorRuntime` is polyfilled is not correct:
```
polyfillGlobal('regeneratorRuntime', () => {
// The require just sets up the global, so make sure when we first
// invoke it the global does not exist
delete global.regeneratorRuntime;
require('regenerator-runtime/runtime');
return global.regeneratorRuntime;
});
```
Since a `require`d module is only evaluated once (no matter how many times it's required), defining (and calling) a getter for `global.regeneratorRuntime` twice will end up storing `undefined` to `global.regeneratorRuntime`.
There were no issues before this diff because the ordering of requires made things work by coincidence, e.g the following code will work:
```
// Set up regenerator for the first time
polyfillGlobal('regeneratorRuntime', () => {
delete global.regeneratorRuntime;
require('regenerator-runtime/runtime');
return global.regeneratorRuntime;
});
// Set up regenerator for the second time. This will just override the previous getter (which has not even got executed so
// the `regenerator-runtime/runtime` module has not been evaluated yet.
polyfillGlobal('regeneratorRuntime', () => {
// The require just sets up the global, so make sure when we first
// invoke it the global does not exist
delete global.regeneratorRuntime;
require('regenerator-runtime/runtime');
return global.regeneratorRuntime;
});
// Now access regenerator
global.regeneratorRuntime;
```
But the following code won't work:
```
// Set up regenerator for the first time
polyfillGlobal('regeneratorRuntime', () => {
delete global.regeneratorRuntime;
require('regenerator-runtime/runtime');
return global.regeneratorRuntime;
});
// Access regenerator. This will cause the previous getter to be called, and the `regenerator-runtime/runtime` module will get evaluated.
// Here, `global.regeneratorRuntime` will have a correct value.
global.regeneratorRuntime;
// Set up regenerator for the second time. This will define a new getter for `global.regeneratorRuntime`, which will delete `delete global.regeneratorRuntime`
// and return undefined (note that `require('regenerator-runtime/runtime');` is a noop since the module has been already evaluated).
polyfillGlobal('regeneratorRuntime', () => {
// The require just sets up the global, so make sure when we first
// invoke it the global does not exist
delete global.regeneratorRuntime;
require('regenerator-runtime/runtime');
return global.regeneratorRuntime;
});
```
Reviewed By: fromcelticpark
Differential Revision: D10483975
fbshipit-source-id: 5b3ef6e11c4fc4f79e3857c1ade9e7bc2beb6a39
Summary: This change drops the year from the copyright headers and the LICENSE file.
Reviewed By: yungsters
Differential Revision: D9727774
fbshipit-source-id: df4fc1e4390733fe774b1a160dd41b4a3d83302a
Summary:
This PR removes the need for having the `providesModule` tags in all the modules in the repository.
It configures Flow, Jest and Metro to get the module names from the filenames (`Libraries/Animated/src/nodes/AnimatedInterpolation.js` => `AnimatedInterpolation`)
* Checked the Flow configuration by running flow on the project root (no errors):
```
yarn flow
```
* Checked the Jest configuration by running the tests with a clean cache:
```
yarn jest --clearCache && yarn test
```
* Checked the Metro configuration by starting the server with a clean cache and requesting some bundles:
```
yarn run start --reset-cache
curl 'localhost:8081/IntegrationTests/AccessibilityManagerTest.bundle?platform=android'
curl 'localhost:8081/Libraries/Alert/Alert.bundle?platform=ios'
```
[INTERNAL] [FEATURE] [All] - Removed providesModule from all modules and configured tools.
Closes https://github.com/facebook/react-native/pull/18995
Reviewed By: mjesun
Differential Revision: D7729509
Pulled By: rubennorte
fbshipit-source-id: 892f760a05ce1fddb088ff0cd2e97e521fb8e825
Summary:
Includes React Native and its dependencies Fresco, Metro, and Yoga. Excludes samples/examples/docs.
find: ^(?:( *)|( *(?:[\*~#]|::))( )? *)?Copyright (?:\(c\) )?(\d{4})\b.+Facebook[\s\S]+?BSD[\s\S]+?(?:this source tree|the same directory)\.$
replace: $1$2$3Copyright (c) $4-present, Facebook, Inc.\n$2\n$1$2$3This source code is licensed under the MIT license found in the\n$1$2$3LICENSE file in the root directory of this source tree.
Reviewed By: TheSavior, yungsters
Differential Revision: D7007050
fbshipit-source-id: 37dd6bf0ffec0923bfc99c260bb330683f35553e
Summary:
This PR is a followup to https://github.com/facebook/react-native/pull/11417 and should be merged after that one is merged.
1. Add support for creating blobs from strings, not just other blobs
1. Add the `File` constructor which is a superset of `Blob`
1. Add the `FileReader` API which can be used to read blobs as strings or data url (base64)
1. Add support for uploading and downloading blobs via `XMLHttpRequest` and `fetch`
1. Add ability to download local files on Android so you can do `fetch(uri).then(res => res.blob())` to get a blob for a local file (iOS already supported this)
1. Clone the repo https://github.com/expo/react-native-blob-test
1. Change the `package.json` and update `react-native` dependency to point to this branch, then run `npm install`
1. Run the `server.js` file with `node server.js`
1. Open the `index.common.js` file and replace `localhost` with your computer's IP address
1. Start the packager with `yarn start` and run the app on your device
If everything went well, all tests should pass, and you should see a screen like this:
![screen shot 2017-06-08 at 7 53 08 pm](https://user-images.githubusercontent.com/1174278/26936407-435bbce2-4c8c-11e7-9ae3-eb104e46961e.png)!
Pull to rerun all tests or tap on specific test to re-run it
[GENERAL] [FEATURE] [Blob] - Implement blob support for XMLHttpRequest
Closes https://github.com/facebook/react-native/pull/11573
Reviewed By: shergin
Differential Revision: D6082054
Pulled By: hramos
fbshipit-source-id: cc9c174fdefdfaf6e5d9fd7b300120a01a50e8c1
Summary: Moves initialization of `Map` and `Set` polyfills to the top of `InitializeCore` to avoid problems with JSC versions that don’t accept (or silently ignore) iterables as constructor arguments.
Reviewed By: mjesun
Differential Revision: D6185632
fbshipit-source-id: 3abe4baeb3a08c328d8c6b3bb1b2e01716c2c95c
Summary:
- The version check that ensures the JS and native versions match is now in its own module for two reasons: it is easier to test and it allows react-native-windows to override just this module to implement its own version check (ex: more advanced checks for RNW-specific code).
- Added unit tests for the version checking to specify its behavior more clearly, including parity between dev and prod to avoid prod-only behavior and mitigate SEVs.
- Prefixed the Obj-C `#define` with `RCT_` to conform with other RN globals.
Closes https://github.com/facebook/react-native/pull/16403
Differential Revision: D6068491
Pulled By: hramos
fbshipit-source-id: 2b255b93982fb9d1b655fc62cb17b126bd5a939a
Summary: In some enviroments PlatformConstants native module may not be presented in a project, which results in a call to undefined property and a RedBox
Reviewed By: javache
Differential Revision: D5960879
fbshipit-source-id: 80aecbe2f2a61cb410abd5f0dce8ba855e166991
Summary:
Basic implementation of the proposal in #15271
Note that this should not affect facebook internally since they are not using OSS releases.
Points to consider:
- How strict should the version match be, right now I just match exact versions.
- Wasn't able to use haste for ReactNativeVersion because I was getting duplicate module provider caused by the template file in scripts/versiontemplates. I tried adding the scripts folder to modulePathIgnorePatterns in package.json but that didn't help.
- Redscreen vs. warning, I think warning is useless because if the app crashes you won't have time to see the warning.
- Should the check and native modules be __DEV__ only?
**Test plan**
Tested that it works when version match and that it redscreens when versions don't before getting other errors on Android and iOS.
Closes https://github.com/facebook/react-native/pull/15518
Differential Revision: D5813551
Pulled By: hramos
fbshipit-source-id: 901757e25724b0f22bf39de172b56309d0dd5a95
Summary:
This is the first PR from a series of PRs grabbou and me will make to add blob support to React Native. The next PR will include blob support for XMLHttpRequest.
I'd like to get this merged with minimal changes to preserve the attribution. My next PR can contain bigger changes.
Blobs are used to transfer binary data between server and client. Currently React Native lacks a way to deal with binary data. The only thing that comes close is uploading files through a URI.
Current workarounds to transfer binary data includes encoding and decoding them to base64 and and transferring them as string, which is not ideal, since it increases the payload size and the whole payload needs to be sent via the bridge every time changes are made.
The PR adds a way to deal with blobs via a new native module. The blob is constructed on the native side and the data never needs to pass through the bridge. Currently the only way to create a blob is to receive a blob from the server via websocket.
The PR is largely a direct port of https://github.com/silklabs/silk/tree/master/react-native-blobs by philikon into RN (with changes to integrate with RN), and attributed as such.
> **Note:** This is a breaking change for all people running iOS without CocoaPods. You will have to manually add `RCTBlob.xcodeproj` to your `Libraries` and then, add it to Build Phases. Just follow the process of manual linking. We'll also need to document this process in the release notes.
Related discussion - https://github.com/facebook/react-native/issues/11103
- `Image` can't show image when `URL.createObjectURL` is used with large images on Android
The websocket integration can be tested via a simple server,
```js
const fs = require('fs');
const http = require('http');
const WebSocketServer = require('ws').Server;
const wss = new WebSocketServer({
server: http.createServer().listen(7232),
});
wss.on('connection', (ws) => {
ws.on('message', (d) => {
console.log(d);
});
ws.send(fs.readFileSync('./some-file'));
});
```
Then on the client,
```js
var ws = new WebSocket('ws://localhost:7232');
ws.binaryType = 'blob';
ws.onerror = (error) => {
console.error(error);
};
ws.onmessage = (e) => {
console.log(e.data);
ws.send(e.data);
};
```
cc brentvatne ide
Closes https://github.com/facebook/react-native/pull/11417
Reviewed By: sahrens
Differential Revision: D5188484
Pulled By: javache
fbshipit-source-id: 6afcbc4d19aa7a27b0dc9d52701ba400e7d7e98f
Summary:
Adding a Babel plugin that will analyze the file looking for any potential candidate to use `regenerator-runtime`, and if so, will inject dynamically the module. The module is injected per file, so we avoid polluting the global environment. The plugin is also able to inject the `require` call beforehand, so that the inliner can pick them and inline them.
The Babel plugin is part of `react-native-babel-preset`, so as long as you are using this preset you are safe. If not, you should include the specific transformer into your list of plugins, as `react-native-babel-preset/transforms/transform-regenerator-runtime-insertion.js`.
Reviewed By: davidaurelio
Differential Revision: D5388655
fbshipit-source-id: dc403f3d5e2d807529eb8569a85c45fec36a6a3e