Summary:
Currently a build warning is thrown by `if (header.BCVersion != runtimeBCVersion) ...` because `runtimeBCVersion` is signed, apparently because `-1` is used to mean that the runtime has no support for bytecode bundles.
This PR splits out the error case of the runtime not supporting BC bundles from the case of a version mismatch.
Tested as much as I could by building and running `UIExplorer` - I haven't attempted to use real bytecode bundles.
Closes https://github.com/facebook/react-native/pull/11806
Differential Revision: D4408608
fbshipit-source-id: a1d868bb2064588e6a20827692629a46b6ba1e74
Summary:
As per janicduplessis recommendation, provide a new synchronous method to replace the necessary synchronous calls and use a warning in the comments (and method name).
**Motivation**
There are currently a number of XCode warnings that show up in a fresh 0.40 install of a react native project. While the project can still be run, this contributes negatively to the development experience -- valid warnings may be ignored and new ones may be added as per https://en.wikipedia.org/wiki/Broken_windows_theory
This addresses one of the warnings, by providing the functionality of a deprecated method in two specific cases where we can't avoid doing synchronous work on the main queue. See https://github.com/facebook/react-native/issues/11736 for more context.
**Test plan (required)**
I ran a project that relied on screen size and it didn't crash...happy to do more involved testing if someone can share better methodology.
Closes https://github.com/facebook/react-native/pull/11817
Differential Revision: D4402911
fbshipit-source-id: 9fd8b3f50d34984b765fe22b1f4512e103ba55a9
Summary:
Strangely comparing a pointer with zero will only be a clang warning when compiling with `-Wpedantic`, so this incorrect comparison is silently allowed.
**Test plan**
Compiles with `-Wpedantic`.
Closes https://github.com/facebook/react-native/pull/11709
Differential Revision: D4377512
Pulled By: ericvicenti
fbshipit-source-id: 483cf1f41d3f539c452d542ad2155c4c4b41616d
Summary: No need to have two files; merge it into one and give it an appropriate name.
Reviewed By: javache
Differential Revision: D4296716
fbshipit-source-id: 904d13c23bb8d403b8efcb60f9a4aa5df5b08972
Summary: This singleton was unnecessary and can be implemented with a single `static` in `RCTDevMenu`. In another diff, I will rename `RCTWebSocketManager.{h,m}` to reflect the only class that remains.
Reviewed By: javache
Differential Revision: D4296551
fbshipit-source-id: 653971dfb31de5b0a161b531eed82a067f536ce3
Summary: Introduces an API to register a weakly-held listener for the reload (Cmd+R) command. This allows external infrastructure to hook into the reload command before the `RCTBridge` object is even created.
Reviewed By: javache
Differential Revision: D4286980
fbshipit-source-id: 51012fb8cbeb433dc880d9d98d847b07fdbb4c4f
Summary:
To make React Native play nicely with our internal build infrastructure we need to properly namespace all of our header includes.
Where previously you could do `#import "RCTBridge.h"`, you must now write this as `#import <React/RCTBridge.h>`. If your xcode project still has a custom header include path, both variants will likely continue to work, but for new projects, we're defaulting the header include path to `$(BUILT_PRODUCTS_DIR)/usr/local/include`, where the React and CSSLayout targets will copy a subset of headers too. To make Xcode copy headers phase work properly, you may need to add React as an explicit dependency to your app's scheme and disable "parallelize build".
Reviewed By: mmmulani
Differential Revision: D4213120
fbshipit-source-id: 84a32a4b250c27699e6795f43584f13d594a9a82
Summary:
When native events where handled they were not sent to JS as an optimization but this caused some issues. One of the major one is touches are not handled properly inside a ScrollView with an Animated.event because it doesn't receive scroll events so it can't cancel the touch if the user scrolled.
Closes https://github.com/facebook/react-native/pull/10981
Differential Revision: D4226403
Pulled By: astreet
fbshipit-source-id: 41278d3ed4b684af142d9e273b11b974eb679879
Summary: Correct header import paths, update podspec so we point at the copy in ReactCommon (and can eventually remove the copy under React)
Reviewed By: astreet
Differential Revision: D4204501
fbshipit-source-id: e979a010092f025b2cdc289e1e5f22fc7b65a8d1
Summary:
The various RCTLog macros (`RCTLogWarn`, `RCTLogError`, etc..) are based on the `_RCTLog` macro, which, in its expanded form, has a semi-colon in DEV mode (i.e., when `RCTLOG_ENABLED` is set to 1), and doesn't have one when `RCTLOG_ENABLED` is set to 0.
This could lead to a situation where code will compile in DEV but will fail to compile for prod.
Fixing this by removing the semicolon from the DEV version (as should).
Reviewed By: javache
Differential Revision: D4189133
fbshipit-source-id: 54cb4e2c96d1e48d9df88464aa58b13af432c2bd
Summary:
This adds native support for `Animated.event` on iOS.
**Test plan**
Tested in the native animated UIExplorer example that it works properly like on Android.
Closes https://github.com/facebook/react-native/pull/9598
Differential Revision: D4110331
fbshipit-source-id: 15748d23d0f475f2bcd1040ca3dca33e2620f058
Summary:
Explain the **motivation** for making this change. What existing problem does the pull request solve?
See https://github.com/facebook/react-native/issues/10506. A native `NSError` with `NSUnderlyingErrorKey` set causes a JSON stringify error from the websocket dispatcher if remote debugging is enabled.
**Test plan (required)**
I'm not familiar with the react native testing framework. Happy to add a test for this if someone can point me to where this part of the codebase is exercised :)
I did some spot checks with nil user dictionaries and nil underlying errors here. The case that this solves is testable using https://github.com/superseriouscompany/react-native-error-repro, specifically:
```objective-c
NSError *underlyingError = [NSError errorWithDomain:@"underlyingDomain" code:421 userInfo:nil];
NSError *err = [NSError errorWithDomain:@"domain" code:68 userInfo:@{@"NSUnderlyingError": underlyingError}];
reject(@"foo", @"bar", err);
```
Closes https://github.com/facebook/react-native/pull/10507
Differential Revision: D4080802
Pulled By: lacker
fbshipit-source-id: 93a41d9e9a710e406a6ccac214a5617271b4bede
Summary: This is a simple hook to allow native side to fetch any file under the js root folder via packager. Historically, only the `main.jsbundle` is fetched via the packager. This then allows fetching local file like a json file that lives under the same root js folder
Reviewed By: yungsters
Differential Revision: D4037730
fbshipit-source-id: a2d6eb5e30d148fee573d413fc4036d0189f4938
Summary:
Packager can take a long time to load and the progress is usually displayed in another window (Terminal). I'm adding support for showing a UI inside React Native app for packager's progress when loading a bundle.
This is how it will work:
1. React Native sends request to packager with `Accept: multipart/mixed` header.
2. Packager will detect that header to detect that client supports progress events and will reply with `Content-Type: multipart/mixed`.
3. While building the bundle it will emit chunks with small metadata (like `{progress: 0.3}`). In the end it will send the last chunk with the content of the bundle.
4. RN runtime will be receiving the events, for each progress event it will update the UI. The last chunk will be the actual bundle which will end the download process.
This workflow is totally backwards-compatible -- normally RN doesn't set the `Accept` header.
Reviewed By: mmmulani
Differential Revision: D3845684
fbshipit-source-id: 5b3d2c5a4c6f4718d7e5de060d98f17491e82aba
Summary:
First commit for Apple TV support: changes to existing Objective-C code so that it will compile correctly for tvOS.
Closes https://github.com/facebook/react-native/pull/9649
Differential Revision: D3916021
Pulled By: javache
fbshipit-source-id: 34acc9daf3efff835ffe38c43ba5d4098a02c830
Summary:
This fixes measuring of items in the main axis of a container. Previously items were in a lot of cases measured with UNSPECIFIED instead of AT_MOST. This was to support scrolling containers. The correct way to handle scrolling containers is to instead provide them with their own overflow value to activate this behavior. This is also similar to how the web works.
This is a breaking change. Most of your layouts will continue to function as before however some of them might not. Typically this is due to having a `flex: 1` style where it is currently a no-op due to being measured with an undefined size but after this change it may collapse your component to take zero size due to the implicit `flexBasis: 0` now being correctly treated. Removing the bad `flex: 1` style or changing it to `flexGrow: 1` should solve most if not all layout issues your see after this diff.
Reviewed By: majak
Differential Revision: D3876927
fbshipit-source-id: 81ea1c9d6574dd4564a3333f1b3617cf84b4022f
Summary:
If we use RCTLogError, we show a redbox with a native stacktrace before we can actually show the JS stacktrace (which is only done through dispatch_async). Instead use RCTLogWarn so its logged to console but not reported as a redbox.
Also fix call to RCTNSErrorFromJSErrorRef off the main thread RCTJSCExecutor.
Reviewed By: majak, mmmulani
Differential Revision: D3886813
fbshipit-source-id: 119d04858cb0c85c79e12ff8a79806711f8e0b27
Summary: Introduce `overflow:scroll` so that scrolling can be implemented without the current overflow:visible hackiness. Currently we use AT_MOST to measure in the cross axis but not in the main axis. This was done to enable scrolling containers where children are not constraint in the main axis by their parent. This caused problems for non-scrolling containers though as it meant that their children cannot be measured correctly in the main axis. Introducing `overflow:scroll` fixes this.
Reviewed By: astreet
Differential Revision: D3855801
fbshipit-source-id: 3c365f9e6ef612fd9d9caaaa8c650e9702176e77
Summary: Introduce `overflow:scroll` so that scrolling can be implemented without the current overflow:visible hackiness. Currently we use AT_MOST to measure in the cross axis but not in the main axis. This was done to enable scrolling containers where children are not constraint in the main axis by their parent. This caused problems for non-scrolling containers though as it meant that their children cannot be measured correctly in the main axis. Introducing `overflow:scroll` fixes this.
Reviewed By: astreet
Differential Revision: D3855801
fbshipit-source-id: 6077b0bcb68fe5ddd4aa22926acab40ff4d83949
Summary:
At the moment, posting RCTReloadNotification in any circumstance causes all RCTBridge instances to reload. This change scopes the notification to the bridge for which it was intended.
Closes https://github.com/facebook/react-native/pull/8762
Differential Revision: D3831914
fbshipit-source-id: ff29574f574ecd1a403057ddd0458dea38f0136e
Summary:
Include CSSLayout headers in the same way as other project headers, ie `#import <CSSLayout/CSSLayout.h>` becomes `#import "CSSLayout.h"`. CSSLayout is not a framework or system dependency, so shouldn't (AFAIK) be included with angle brackets. Doing so breaks framework builds, such as when RN is used as a pod in a swift project.
In combination with https://github.com/facebook/css-layout/pull/217 this fixes https://github.com/facebook/react-native/issues/9014 (specifically swift cocoapods projects). There is then no need for a separate CSSLayout pod subspec.
Tests run on the RN project in isolation (with changes inside `CSSLayout` itself also applied) and against a dummy swift project with RN included as a pod.
NB: This effectively reverts https://github.com/facebook/react-native/pull/9015 and may break non-swift cocoapods projects unless https://github.com/facebook/css-layout/pull/217 is merged and synced first.
Update: As discussed with alloy and emilsjolander, wrap these imports in a preprocess
Closes https://github.com/facebook/react-native/pull/9544
Differential Revision: D3821791
Pulled By: javache
fbshipit-source-id: d27ac8be9ce560d03479b43d3db740cd196c24da
Summary:
First of all,please forgive my poor english. LOL
When I use Promises as callBack,
I followed the guide to make a (RCTPromiseRejectBlock),in this RCTPromiseRejectBlock,
from the guide I should add a (NSString)code a (NSString)message and an (NSError) to a RCTPromiseRejectBlock.
As what did guide said I just make a NSError with
```
NSError *error=[NSError errorWithDomain:@"native stroage error" code:402 userInfo:@{@"data":key}];
```
As you can see, I want to transfer some data in this callback.But I just found the (userInfo) of NSError didn't composed to a RCTPromiseRejectBlock.
So I check out the source code of RCTUtil ,I found this
```
// TODO: Can we just replace RCTMakeError with this function instead?
NSDictionary<NSString *, id> *RCTJSErrorFromCodeMessageAndNSError(NSString *code,
NSString *message,
NSError *__nullable error)
{
NSString *errorMessage;
Closes https://github.com/facebook/react-native/pull/9519
Differential Revision: D3821334
Pulled By: javache
fbshipit-source-id: 0fa40dd93932af70123b8f8a20a5c7dc5afdd6ac
Summary:
The overflow prop needs to be set on the shadow view so that it can make its way into the layout engine. In some situations, the value of the overflow prop affects the calculations of the layout engine.
**Test plan (required)**
Verified in a test app that the `overflow` prop makes its way into the layout engine. Also, my team's app is currently using this change.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/9659
Differential Revision: D3790552
fbshipit-source-id: 61513ece63ae214f48c6cb6f40fb29757a0ac706
Summary:
**Motivation:** We have a project that dynamically changes classes in runtime. This component is initialised within the React Native context. Therefor `RCTBatchedBridge` copies the classes before changes are made to them. While React Native is running, changes are made to the classes dynamically. When the project reloads the `RCTBatchedBridge`, it now has an invalid list of classes containing trash pointers. This causes the project to crash on https://github.com/facebook/react-native/blob/master/React/Base/RCTBatchedBridge.m#L288 with EXC_BAD_ACCESS in the DEBUG-mode.
**Solution:** Copy the class list on each reload to get the current state. Since this is only a DEBUG-feature the overhead of this should not be a major issue.
Closes https://github.com/facebook/react-native/pull/9541
Differential Revision: D3775012
Pulled By: javache
fbshipit-source-id: d55fa0742ca100d8018c73080230cf718aa5a7e9
Summary:
Ground work for allowing `font-variant`s. Currently allows switching between `tabular-nums` and `proportional-nums`. I will need guidance on how to test this, and a few pointers on code style (new to Objective C, and had to make one or two hacks).
Closes https://github.com/facebook/react-native/pull/9045
Reviewed By: majak
Differential Revision: D3664338
Pulled By: javache
fbshipit-source-id: 032f326c37ee6150348da2b33b6a3fc1988e8920
Summary:
When you call `-[RCTConvert UIFont:withFamily:...]` with a non-nil font object, we'll try to use the existing font object for system information. On iOS9+ which uses the San Francisco font, `[UIFont fontNamesForFamilyName:]` doesn't return anything useful, so we need to make sure that we detect this as a system font and use the appropriate methods. This issues is made worse by the fact that RCTTextView and friends recreate the font property for every attribute that is set (pretty horrible perf-wise).
This fixes https://github.com/facebook/react-native/issues/2140
Reviewed By: sahrens
Differential Revision: D3662751
fbshipit-source-id: c528e8945ed361a922c03f861d3c0b584658573b
Summary: Mirrors Android's support for multiple sources for Image, allowing us to fetch new images as the size of the view changes.
Reviewed By: mmmulani
Differential Revision: D3615134
fbshipit-source-id: 3d0bf2b75f63a4379e0e49f2dab9aea351b31d5f
Summary:
This uses `[UIImage imageNamed:]` to load local assets that are bundled using `require('../image/path.png')` and makes sure it is done synchronously on the main queue to prevent images from flickering. This improves user experience a lot when using large local images and prevents icon flickers to match the behaviour of most native apps.
This adds to methods to the ImageLoader protocol, one to tell if the image loader must be executed on the url cache queue and one to tell if the result of the image loader should be cached. I then use these to make the LocalImageLoader bypass the url cache queue and avoid caching images twice.
Note that this doesn't affect debug builds since images are loaded from the packager.
I'm not sure if we want to still support async loading of local images as I'm not sure how much of a perf difference this will make. Maybe someone at fb can benchmark this see how it affects your apps but there wasn't a noticeable one in mine. Also I only enabled this for loading png and jpg im
Closes https://github.com/facebook/react-native/pull/8102
Reviewed By: bnham
Differential Revision: D3433647
Pulled By: javache
fbshipit-source-id: 37bd6aff20c0465c163db3cdbcaeaedff55f7b1f
Summary: Instead of the somewhat odd concept of a "packager running predicate", just expose a class method for generating a JS bundle URL given a host, root, and options. This can be used by consumers that need custom behavior.
Reviewed By: javache
Differential Revision: D3564185
fbshipit-source-id: b1a7e66a2dada6a9eefe783b12b03fca7a330be3
Summary: The docs for this new method explain what it does.
Differential Revision: D3556890
fbshipit-source-id: b075e750cdd1e7354e0a26c03b3fd74cca52aeb7
Summary:
- Avoid using `+initialize`, use dispatch_once instead; it should be equivalent but more performant.
- Don't even let the `isPackagerRunning:` and `guessPackagerHost` methods exist unless `RCT_DEV` is on; they didn't do anything interesting when it is off.
Reviewed By: javache
Differential Revision: D3556645
fbshipit-source-id: 7dcdb4ae27f6625010e15846d757269f6f04155c
Summary: Include the actual scheme instead of "non-file".
Reviewed By: javache
Differential Revision: D3555812
fbshipit-source-id: 3ae0490f2d8fae01a551ba2877789dc15818fc50
Summary:
WebView component detect phone numbers in html as URL links by default. But sometimes we don't want this behavior.
This PR add dataDetectorTypes as a prop of WebView, so one can specify value of this prop as one or more of phoneNumber/link/address/calendarEvent/none/all
This prop maps to UIWebView.dataDetectorTypes
Closes https://github.com/facebook/react-native/pull/8743
Differential Revision: D3556440
fbshipit-source-id: 55f01d2cdd785381f261a9dc931aa9311f0ad1d4
Summary: The loader should be a utility that stands alone. The bridge uses the loader, not the other way around.
Reviewed By: bnham
Differential Revision: D3546157
fbshipit-source-id: 91016afb629df1f8c83c8fca6f42649be0b046b0
Summary:
This diff exposes a new experimental method `[RCTJavaScriptLoader +attemptSynchronousLoadOfBundleAtURL:sourceLength:error:]`. It may be used if you know that a specific call site must load its JavaScript synchronously, or else fail entirely.
This new API will succeed for file URLs that point to a RAM bundle. It will fail for non-RAM-bundle files and for HTTP URLs.
This also cleans up the error domain and codes for this class. This should be the only externally visible change from this diff if you don't use the new API: the codes and domains you receive from the API may change slightly. They were pretty sloppy and undocumented before, so I think this change is for the better.
Reviewed By: bnham
Differential Revision: D3545956
fbshipit-source-id: 30e65f4e8330d2d68f3f50ade077fdc1db4a435e
Summary:
By default we run the the JS display link, even if there are no modules listening. Given that most listeners will be lazily constructed, let's make it paused by default.
Since RCTTiming almost never unpauses due to some long-lived timers, implement a sleep timer that pauses the displaylink but uses an NSTimer to wake up in time.
Reviewed By: mhorowitz
Differential Revision: D3235044
fbshipit-source-id: 4a340fea552ada1bd8bc0d83b596a7df6f992387
Summary:
Currently React Native codebase treats JS stack traces as array of dictionaries.
This diff switches the Red Box to use new `RCTJSStackFrame` for internal data representation, while keeping the exposed API unchanged. The next step would be to replace the rest of manual parsing and usage of dictionaries.
The new class has ability to parse the stack from raw strings or dictionaries.
Depends on D3429031
Reviewed By: javache
Differential Revision: D3473199
fbshipit-source-id: 90d2a4f5e8e054b75c99905f35c2ee54927bb311
Summary: This leaves no optional methods on `RCTJavaScriptExecutor`, which is certainly a good thing.
Reviewed By: majak
Differential Revision: D3518915
fbshipit-source-id: e606b9076c3299f81a225a181ea244148a1832cb
Summary: It's not widely used, and you can do something equivalent anyway by using existing public API.
Reviewed By: javache
Differential Revision: D3518896
fbshipit-source-id: 6995a5d840aecfff4ffd78ac43f3f592a4f47f91
Summary: Reading four bytes is not slow. Don't bother dispatching for that.
Reviewed By: javache
Differential Revision: D3518405
fbshipit-source-id: 910079cec2a1f624dd71760438765bd035055229
Summary: No need to have these way at the top; they're not used until later.
Reviewed By: majak
Differential Revision: D3518364
fbshipit-source-id: 3e7461665e90dea5c6d323d45b1ffb11fb610b09
Summary: No need to keep it open; it just makes it harder to reason about error handling.
Reviewed By: majak
Differential Revision: D3518200
fbshipit-source-id: dc1af6eb0f75de7e9f73513ed1dd522048f76670
Summary:
Thanks for submitting a pull request! Please provide enough information so that others can review your pull request:
(You can skip this if you're fixing a typo or adding an app to the Showcase.)
Explain the **motivation** for making this change. What existing problem does the pull request solve?
Prefer **small pull requests**. These are much easier to review and more likely to get merged. Make sure the PR does only one thing, otherwise please split it.
**Test plan (required)**
Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes UI.
Make sure tests pass on both Travis and Circle CI.
**Code formatting**
Look around. Match the style of the rest of the codebase. See also the simple [style guide](https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md#style-guide).
For more info, see the ["Pull Requests" section of our "Contributing" guidelines](https://github.com/facebook/react-native/blob/mas
Closes https://github.com/facebook/react-native/pull/7535
Differential Revision: D3509757
fbshipit-source-id: 70ff6c9c137c766ccb1173921f08571f48cb4f0b
Summary:
Implemented automatic IP detection for iOS, based on #6345 and #6362.
As the previous pull requests did, this works by writing the IP address of the host to a file.
Closes https://github.com/facebook/react-native/pull/8091
Differential Revision: D3427657
Pulled By: javache
fbshipit-source-id: 3f534c9b32c4d6fb9615fc2e2c3c3aef421454c5
Summary:
After cleaning up JS SourceMap code, these native methods are not needed anymore.
On iOS it saves another 30+ Mb during development.
Reviewed By: javache, astreet
Differential Revision: D3348975
fbshipit-source-id: a68ae9b00b4dbaa374b421029ae676fc69ae5a75
Summary:
This diff refactors the view update process into two stages:
1. The `reactSubviews` array is set, whose order matches the order of the JS components and shadowView components, as specified by the UIManager.
2. The `didUpdateReactSubviews` method is called, which actually inserts the reactSubviews into the view hierarchy.
This simplifies a lot of the hacks we had for special-case treatment of subviews: In many cases we don't want to actually insert `reactSubviews` into the parentView, and we had a bunch of component-specific solutions for that (typically overriding all of the reactSubviews methods to store views in an array). Now, we can simply override the `didUpdateReactSubviews` method for those views to do nothing, or do something different.
Reviewed By: wwjholmes
Differential Revision: D3396594
fbshipit-source-id: 92fc56fd31db0cfc66aac3d1634a4d4ae3903085
Summary:
This is a followup for "Add Shortcut "Double R" to Reload JS in iOS".
Please see the previous two revisions:[[ D3371536 | D3371536 ]], [[ D3343907 | D3343907 ]]
In previous revisions, we only tested with the iOS UIExplorer app, without testing in the iOS Catalyst app, where the key shortcuts we added are always invoked in TextInput components. It's due to a bug with the `UIApplicationDelegate`. Just fix this bug in this revision and successfully tested in the Catalyst app.
Reviewed By: mkonicek
Differential Revision: D3391045
fbshipit-source-id: 8b76fbfe7592218b02dd22502d25eebbc59f3cbc
Summary:
As per https://twitter.com/olebegemann/status/738656134731599872, our use of "main thread" to mean "main queue" seems to be unsafe.
This diff replaces the `NSThread.isMainQueue` checks with dispatch_get_specific(), which is the recommended approach.
I've also replaced all use of "MainThread" terminology with "MainQueue", and taken the opportunity to deprecate the "sync" param of `RCTExecuteOnMainThread()`, which, while we do still use it in a few places, is incredibly unsafe and shouldn't be encouraged.
Reviewed By: javache
Differential Revision: D3384910
fbshipit-source-id: ea7c216013372267b82eb25a38db5eb4cd46a089
Summary:
Allows developers to specify headers to include in the HTTP request
when fetching a remote image. For example, one might leverage this
when fetching an image from an endpoint that requires authentication:
```
<Image
style={styles.logo}
source={{
uri: 'http://facebook.github.io/react/img/logo_og.png',
headers: {
Authorization: 'someAuthToken'
}
}}
/>
```
Note that the header values must be strings.
Works on iOS and Android.
**Test plan (required)**
- Ran a small example like the one above on iOS and Android and ensured the headers were sent to the server.
- Ran a small example to ensure that \<Image\> components without headers still work.
- Currently using this code in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/7338
Reviewed By: javache
Differential Revision: D3371458
Pulled By: nicklockwood
fbshipit-source-id: cdb24fe2572c3ae3ba82c86ad383af6d85157e20
Summary:
Enable double tap R on iOS, consistent with Android.
Keep the existing Cmd+R on iOS because people are already used to it.
Make Cmd+Key and Double Key both invalid when focus is in textview or textfield.
Also try to add Cmd+R in Android, but seems no good.
Reviewed By: nicklockwood
Differential Revision: D3343907
fbshipit-source-id: 68f7e3b0393711c137e1d932db33e1b6a2a19e09
Summary: This will make error messages more helpful.
Reviewed By: javache
Differential Revision: D3292400
fbshipit-source-id: d1e0bb24593058b75422824c0d351ede1320029e
Summary: AppState now subclasses NativeEventEmitter instead of using global RCTDeviceEventEmitter.
Reviewed By: javache
Differential Revision: D3310488
fbshipit-source-id: f0116599223f4411307385c0dab683659d8d63b6
Summary:
On iPad we may get two touch cancel events in direct succession. They would have the same coalescing key, which would result in unsuccesful attempt to coalesce them.
This diff fixes it by making sure two cancel events cannot have the same coalescing key.
(An alternative fix would be implementing coalescing logic for cancel events, but that sounds more complicated. It would be neccessary if there is a legit scenario where big number of cancel events are emitted in succesion.)
Reviewed By: javache
Differential Revision: D3292405
fbshipit-source-id: 1f269771dc81fdd637cf6ac3ee4725e5e2fec679
Summary:
This is a solution for the problem I raised in https://www.facebook.com/groups/react.native.community/permalink/768218933313687/
I've added a new native base class, `RCTEventEmitter` as well as an equivalent JS class/module `NativeEventEmitter` (RCTEventEmitter.js and EventEmitter.js were taken already).
Instead of arbitrary modules sending events via `bridge.eventDispatcher`, the idea is that any module that sends events should now subclass `RCTEventEmitter`, and provide an equivalent JS module that subclasses `NativeEventEmitter`.
JS code that wants to observe the events should now observe it via the specific JS module rather than via `RCTDeviceEventEmitter` directly. e.g. to observer a keyboard event, instead of writing:
const RCTDeviceEventEmitter = require('RCTDeviceEventEmitter');
RCTDeviceEventEmitter.addListener('keyboardWillShow', (event) => { ... });
You'd now write:
const Keyboard = require('Keyboard');
Keyboard.addListener('keyboardWillShow', (event) => { ... });
Within a component, you can also use the `Subscribable.Mixin` as you would previously, but instead of:
this.addListenerOn(RCTDeviceEventEmitter, 'keyboardWillShow', ...);
Write:
this.addListenerOn(Keyboard, 'keyboardWillShow', ...);
This approach allows the native `RCTKeyboardObserver` module to be created lazily the first time a listener is added, and to stop sending events when the last listener is removed. It also allows us to validate that the event strings being observed and omitted match the supported events for that module.
As a proof-of-concept, I've converted the `RCTStatusBarManager` and `RCTKeyboardObserver` modules to use the new system. I'll convert the rest in a follow up diff.
For now, the new `NativeEventEmitter` JS module wraps the `RCTDeviceEventEmitter` JS module, and just uses the native `RCTEventEmitter` module for bookkeeping. This allows for full backwards compatibility (code that is observing the event via `RCTDeviceEventEmitter` instead of the specific module will still work as expected, albeit with a warning). Once all legacy calls have been removed, this could be refactored to something more elegant internally, whilst maintaining the same public interface.
Note: currently, all device events still share a single global namespace, since they're really all registered on the same emitter instance internally. We should move away from that as soon as possible because it's not intuitive and will likely lead to strange bugs if people add generic events such as "onChange" or "onError" to their modules (which is common practice for components, where it's not a problem).
Reviewed By: javache
Differential Revision: D3269966
fbshipit-source-id: 1412daba850cd373020e1086673ba38ef9193050
Summary:
Modules which call JS methods directly, or use `sendDeviceEventWithName:`, can trigger effects in JS without ever being referenced from the JS code. This breaks some assumptions in my earlier diff about when modules can be lazily loaded.
Pending a better solution, I've put explicit `init` methods in these modules to ensure they are eagerly initialized (the downside to this is that they'll still be initialized even if they are never used).
Reviewed By: javache
Differential Revision: D3258232
fb-gh-sync-id: f925bc2e5339c1fbfcc244d4613062c5ab848fc2
fbshipit-source-id: f925bc2e5339c1fbfcc244d4613062c5ab848fc2
Summary:
Previously, if a module implemented `setBridge:` we assumed that it needs to be initialised on the main thread. This assumption was not really warranted however, and it was a barrier to deferring module initialization.
This diff tweaks the rules so that only modules that override `init` or `constantsToExport**` are assumed to require main thread initialization, and others can be created lazily when they are first used.
WARNING: this will be a breaking change to any 3rd party modules that are assuming `setBridge:` is called on the main thread. Those modules should be rewritten to move any code that requires the main thread into `init` or `constantsToExport` instead.
`**` We will also be examining whether `constantsToExport` can be done lazily, but for now any module that uses it will still be created eagerly when the bridge starts up.
Reviewed By: javache
Differential Revision: D3240682
fb-gh-sync-id: 48f309e3158bbccb52141032baf70def3e609371
fbshipit-source-id: 48f309e3158bbccb52141032baf70def3e609371
Summary: Using customDirectEventTypes or customBubblingEventTypes causes a viewmanager to be initialized at app start. This diff deprecates those methods and removes their usage from RCTScrollViewManager.
Reviewed By: majak
Differential Revision: D3218973
fb-gh-sync-id: 295bef3be9623b49b0cdcbf8a56e10d9b28126d9
fbshipit-source-id: 295bef3be9623b49b0cdcbf8a56e10d9b28126d9
Summary:
Now that we support initializing the bridge off the main thread, some of the assumptions in the bridge setup process are no longer safe.
In particular we were assuming that the JS executor and injected modules could always be synchronously initialized within bridge init, but that is only safe if those modules don't need to be set up on the main thread.
The setup for those modules was sync-dispatching to the main thread if bridge init happened on a background thread, and this lead to a deadlock under certain circumstances.
Reviewed By: javache
Differential Revision: D3224162
fb-gh-sync-id: 7319b70f541a46ef932cfe4f776e7e192f3ce1e8
fbshipit-source-id: 7319b70f541a46ef932cfe4f776e7e192f3ce1e8
Summary:When JSC throws an error on startup (e.g. a SyntaxError) or when invoking a method that is not caught by RCTExceptionsManager, we previously just reported is a native error, with a (useless) native stack trace in the redbox. This changes that behaviour to report a JS stacktrace.
The same issue was previously reported here: https://github.com/facebook/react-native/pull/5677
Reviewed By: majak
Differential Revision: D3037387
fb-gh-sync-id: 06f8333e0eb50dcef0b26284754262301b8a5f08
fbshipit-source-id: 06f8333e0eb50dcef0b26284754262301b8a5f08
Summary:Turns our using the same coalescing key until a person removes all fingers off screen is not ideal.
It doesn't work in a case where the first finger starts moving on screen and then a second finger joins it later (almost any pinch gesture),
since we would try to coalesce move events from the start when only one finger was touching screen with events where two fingers were moving on screen.
That doesn't work and results in a crash.
I've changed the logic for generating the coalescing key in order to prevent this.
We no longer have a single key for a single gesture, but we change the key each time amount of fingers increases ("touchStart") or decreases ("touchEnd").
Reviewed By: javache
Differential Revision: D3138275
fb-gh-sync-id: c32230ba401819fe3a70d1752b286d849520be89
fbshipit-source-id: c32230ba401819fe3a70d1752b286d849520be89
Summary:D3092867 / 1d3db4c5dc caused deadlock when chrome debugging was turned on, so it was reverted as D3128586 / 144dc30661.
The reason: I was calling `[_bridge dispatchBlock:^{ [self flushEventsQueue]; } queue:RCTJSThread];` from main thread and expecting it will `dispatch_async` to another,
since a held lock was being accessed the dispatched block and was released after the dispatch.
Turns out `RCTWebSocketExecutor` (which is used when chrome debugger is turned on) executes all blocks dispatched this way to `RCTJSThread` synchronously on the main thread.
This resulted in a deadlock. The "dispatched" block was trying to acquired lock which held by the same thread in the dispatching phase.
A fix for this is pretty simple. We will release the lock before dispatching the block.
However it's not super straightforward to see this won't introduce some race condition in a case with two threads where we would end up with events not being processed.
My thinking why that shouldn't happen goes like this: We could get in a bad state if `flushEventsQueue` would run on JS thread while `sendEvent:` is running on MT.
(I don't have a specific example how, maybe it's not possible. However when I show this case is safe we know we are good.)
The way how locking is setup in this diff the only possible scenario where these two threads would execute in these methods concurrently is JS holding the lock and MT going to enqueue another block on JS thread (since that's outside of "locked" zone).
But this scenarion can never happen, since if MT is about to enqueue the block on JS thread it means there cannot be a not yet fully executed block on JS thread.
Therefore nothing bad can happen.
So this diff brings back the reverted diff and adds to it the fix for the deadlock.
Reviewed By: javache
Differential Revision: D3130375
fb-gh-sync-id: 885a166f2f808551d7cd4e4eb98634d26afe6a11
fbshipit-source-id: 885a166f2f808551d7cd4e4eb98634d26afe6a11
Summary:The 200ms timeout was causing resource issues and causing a lot of overhead when you're not running the devtools, since it will basically create a new socket every 200ms.
Also clean up the way we do logging so it's completely compiled out in prod, and standardize all the names we use for threading to lowercase react.
Reviewed By: frantic
Differential Revision: D3115975
fb-gh-sync-id: e6e51c0621d8e9fc4eadb864acd678b8b5d322a1
fbshipit-source-id: e6e51c0621d8e9fc4eadb864acd678b8b5d322a1
Summary:Previously, (mostly touch and scroll) event handling on iOS worked in a hybrid way:
* All incoming coalesce-able events would be pooled and retrieved by js thread in the beginning of its frame (all of this happens on js thread)
* Any non-coalesce-able event would be immediately dispatched on a js thread (triggered from main thread), and if there would be pooled coalesce-able events they would be immediately dispatched at first too.
This behavior has a subtle race condition, where two events are produced (on MT) in one order and received in js in different order.
See https://github.com/facebook/react-native/issues/5246#issuecomment-198326673 for further explanation of this case.
The new event handling is (afaik) what Android already does. When an event comes we add it into a pool of events and dispatch a block on js thread to inform js there are events to be processed. We keep track of whether we did so, so there is at most one of these blocks waiting to be processed. When the block is executed js will process all events that are in pool at that time (NOT at time of enqueuing the block).
This creates a single way of processing events and makes it impossible to process them in different order in js.
The tricky part was making sure we don't coalesce events across gestures/different scrolls. Before this was achieved by knowing that gestures and scrolls start/end with non-coalesce-able event, so the pool never contained events that shouldn't be coalesced together. That "assumption" doesn't hold now.
I've re-added `coalescingKey` and made touch and scroll events use it to prevent coalescing events of the same type that should remain separate in previous diffs (see dependencies).
On top of it it decreases latency in events processing in case where we get only coalesce-able events. Previously these would be processed at begging of the next js frame, even when js would be free and could process them sooner. This delay is done, since they would get processed as soon as the enqueued block would run.
To illustrate this improvement let's look at these two systraces.
Before: https://cloud.githubusercontent.com/assets/713625/14021417/47b35b7a-f1d3-11e5-93dd-4363edfa1923.png
After: https://cloud.githubusercontent.com/assets/713625/14021415/4798582a-f1d3-11e5-8715-425596e0781c.png
Reviewed By: javache
Differential Revision: D3092867
fb-gh-sync-id: 29071780f00fcddb0b1886a46caabdb3da1d5d84
fbshipit-source-id: 29071780f00fcddb0b1886a46caabdb3da1d5d84
Summary: This was previously removed in D2884587, but we will need it going forward. See D3092867 for reasons why it's necessary again.
Reviewed By: javache
Differential Revision: D3092848
fb-gh-sync-id: 0d10dbac4148fcc8e035d32d8eab50f876d99e88
fbshipit-source-id: 0d10dbac4148fcc8e035d32d8eab50f876d99e88
Summary:Interface to `RCTBatchedBridge` was being declared in two different implementation files. This is suboptimal, since it makes it hard to mock that class in a test.
So I've merged and moved these two definitions in `RCTBridge+Private.h`, so it's still obvious it's a private class, but can be included if you really need it.
Reviewed By: javache
Differential Revision: D3126135
fb-gh-sync-id: 173e4c5c2925be387b92deb7f99952ca7bf28588
fbshipit-source-id: 173e4c5c2925be387b92deb7f99952ca7bf28588
Summary:`flowIDMap` lives on the bridge to map from the IDs used for the flow events in
JS and the ones generated by `RCTProfile` in the native side.
It was being accessed from multiple threads (the various modules' queues in the
bridge and the JS thread), so we lock before touching it.
Reviewed By: javache
Differential Revision: D3102745
fb-gh-sync-id: 93d012d124e8b5d1a390c10a98ef5e3a068ccf63
fbshipit-source-id: 93d012d124e8b5d1a390c10a98ef5e3a068ccf63
Summary:It was hard to understand which parts of the shadowview API are designed to be called only on the root view, and which were applicable to any view.
This diff extracts rootview-specific logic out into a new RCTRootShadowView class.
Reviewed By: majak
Differential Revision: D3063905
fb-gh-sync-id: ef890cddfd7625fbd4bf5454314b441acdb03ac8
shipit-source-id: ef890cddfd7625fbd4bf5454314b441acdb03ac8
Summary: For RAM bundling we don't want to hold the entire bundle in memory as that approach doesn't scale. Instead we want to seek and read individual sections as they're required. This rev does that by detecting the type of bundle we're dealing with by reading the first 4 bytes of it. If we're dealing with a RAM Bundle we bail loading.
Reviewed By: javache
Differential Revision: D3026205
fb-gh-sync-id: dc4c745d6f00aa7241203899e5ba136915efa6fe
shipit-source-id: dc4c745d6f00aa7241203899e5ba136915efa6fe
Valentin Shergin
rh389
Emil Sjolander
Neil Sarkar
Dan Caspi
Dave Lee
Pieter De Baets
Theo Yaung
Adam Ernst
David Aurelio
Janic Duplessis
Ashok Menon
James Ide
Kevin Gozali
Alex Kotliarskyi
Ovidiu Viorel Iepure
Marc Horowitz
Douglas Lowder
littlesome
Alexey Lang
Ben Roth
BaihaoTian
Scott Wolchok
Adam Comella
Kasper Hirvikoski
Jacob Parker
Nathan Azaria
David Goldman
yueshuaijie
Skotch Vail
Michael McKinley
Siqi Liu
Yinan Na
Sokovikov
Fabian Eichinger
Nick Lockwood
Li Jie
Anoop Chaurasiya
Martin Kralik
Mike Grabowski
Oleg Lokhvitsky
Justin Zeus
Tadeu Zagallo
Michelle Hwang
Martín Bigio
