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
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