Summary:
1. [ios] upgrade folly to 2021.06.28.00 which aligned to android.
2. folly compile setting from c++14 -> c++17: _this folly requires c++17 for `std::unordered_map::insert_or_assign`._
3. boost 1.63.0 -> 1.76.0: _the old boost does not support c++17._
4. deprecating react-native-community/boost-for-react-native: _by cocoapods installer, we could download the official target._
## Changelog
[iOS] [Changed] - Upgrade folly to 2021.06.28.00 and boost to 1.76.0
Pull Request resolved: https://github.com/facebook/react-native/pull/31840
Test Plan: CI passed
Reviewed By: fkgozali
Differential Revision: D29668480
Pulled By: yungsters
fbshipit-source-id: 98eae9ca47f489dcea91974e6f5e9dcb4d66c40c
Summary:
This was causing an upload error in FB Dating, will need to re-land with the fix.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D29320144
fbshipit-source-id: 5d09dd2171b5696afe89cffa064947f0a0bb413d
Summary:
In D28630805 (f78526ce3d) ([github link](https://github.com/facebook/react-native/pull/31457)) I added a setter to workaround a bug I perceived with `moduleRegistry`. Turns out - the proper fix was to remove the `synthesize` line. See conversation on linked diff for more context.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D29144717
fbshipit-source-id: aa95b670b540b9007eed76769c9babc10ea399ce
Summary:
Fixes https://github.com/facebook/react-native/issues/27099
When you upload a local file using XHR + the `FormData` API, RN uses `RCTNetworkTask` to retrieve the image file data from the local filesystem (request URL is a file:// URL) ([code pointer](https://github.com/facebook/react-native/blob/master/Libraries/Network/RCTNetworking.mm#L398)). As a result, if you are uploading a local image file that is in the app's directory `RCTNetworkTask` will end up using `RCTLocalAssetImageLoader` to load the image, which reads the image into a `UIImage` and then re-encodes it using `UIImageJPEGRepresentation` with a compression quality of 1.0, which is the higest ([code pointer](4c5182c1cc/Libraries/Image/RCTImageLoader.mm (L1114))). Not only is this unnecessary, it ends up inflating the size of the jpg if it had been previously compressed to a lower quality.
With this PR, this issue is fixed by forcing the `RCTFileRequestHandler` to be used when retrieving local files for upload, regardless of whether they are images or not. As a result, any file to be uploaded gets read into `NSData` which is the format needed when appending to the multipart body.
I considered fixing this by modifying the behavior of how the handlers were chosen, but this felt like a safer fix since it will be scoped to just uploads and wont affect image fetching.
## Changelog
[iOS] [Fixed] - Avoid re-encoding images when uploading local files
Pull Request resolved: https://github.com/facebook/react-native/pull/31457
Test Plan:
The repro for this is a bit troublesome, especially because this issue doesn't repro in RNTester. There is [some code](https://github.com/facebook/react-native/blob/master/packages/rn-tester/RNTester/AppDelegate.mm#L220) that is to be overriding the handlers that will be used, excluding the `RCTImageLoader`. I had to repro this in a fresh new RN app.
1. Create a blank RN app
2. Put an image in the folder of the app's install location. This would be similar to where files might be placed after an app downloads or captures an image.
3. Set up a quick express server that accepts multipart form uploads and stores the files
4. Trigger an upload via react native
```
const data = new FormData();
data.append('image', {
uri:
'/Users/arthur.lee/Library/Developer/CoreSimulator/Devices/46CDD981 (d0c8cb12f2)-9164-4925-9025-1A76C0D9 (1946aee3d9)F0F5/data/Containers/Bundle/Application/B1E8A764-6221-4EA9-BE9A-2CB1699FD218 (1c92b1cff6)/test.app/test.bundle/compressed.jpg',
type: 'image/jpeg',
name: 'image.jpeg',
});
fetch(`http://localhost:3000/upload`, {
method: 'POST',
headers: {'Content-Type': 'multipart/form-data'},
body: data,
}).then(console.log);
```
5. Trigger the upload with and without this patch
Original file:
```
$ ls -lh
total 448
-rw-r--r-- 1 arthur.lee staff 223K Apr 29 17:08 compressed.jpg
```
Uploaded file (with and without patch):
```
$ ls -lh
total 1624
-rw-r--r--@ 1 arthur.lee staff 584K Apr 29 17:11 image-nopatch.jpeg
-rw-r--r--@ 1 arthur.lee staff 223K Apr 29 17:20 image-withpatch.jpeg
```
Would appreciate pointers on whether this needs to be tested more extensively
Reviewed By: yungsters
Differential Revision: D28630805
Pulled By: PeteTheHeat
fbshipit-source-id: 606a6091fa3e817966548c5eb84b19cb8b9abb1c
Summary:
While it is possible in the React Native implementation for Android to provide a custom configuration for HTTP requests, the iOS implementation does not allow for the same customization. As the NSURLSession used for HTTP requests on iOS is configured internally, one may for instance not supply an ephemeral configuration for HTTP requests. Other concerns related to the given problem have been addressed in the community: https://github.com/react-native-community/discussions-and-proposals/issues/166. I did make a PR with an RFC in the community repo, but after some discussion in the said repo, I figured I might as well make a PR with a suggestion :)
## Changelog
[iOS] [Added] - Allow for configuring the NSURLSessionConfiguration
Implement a C function `RCTSetCustomNSURLSessionConfigurationProvider` which gives the app programmer the ability to provide a block which provides an NSURLSessionConfiguration that will be used for all HTTP requests instead of the default configuration. The provided block will be called when the session configuration is needed.
Pull Request resolved: https://github.com/facebook/react-native/pull/27701
Test Plan: Unsure if this can be tested in any other way than uncommenting the example code in `RNTester/RNTester/AppDelegate.mm`.
Reviewed By: yungsters
Differential Revision: D28680384
Pulled By: JoshuaGross
fbshipit-source-id: ae24399955581a1cc9f4202f0f6f497bfe067a5c
Summary:
This pre-suppresses the 153 error diff ahead of its release, since it is large.
Changelog: [Internal]
Reviewed By: mroch
Differential Revision: D28754374
fbshipit-source-id: 1806f53bc7d804644d434583a2dcd6da63d00328
Summary:
This fixes an error where folly fails to build on Xcode 12.5, by bumping the various folly deps in RN to builds with a fix.
Next step is to commit this to 0.64 release branch
allow-large-files
Changelog: [iOS] Fix builds on Xcode 12.5
Reviewed By: fkgozali
Differential Revision: D28071808
fbshipit-source-id: 236b66bf8294db0c76ff25b11632c1bf89525921
Summary:
This intentionally leaks the static map, since it still might be accessed after static destructors are run. This is a common approach to this problem, see https://github.com/facebook/react-native/pull/22607 and https://github.com/facebook/componentkit/pull/906 as examples. It also sets up an autorelease pool from `RCTNativeModule::invoke` as a precaution since there's no strict guarantee one exists when it is called.
Changelog:
[iOS][Fixed] - Fix crash in RCTCoreModulesClassProvider during quit
Reviewed By: RSNara
Differential Revision: D27932062
fbshipit-source-id: fa75da4b78290027a762440ac6943c81b8594a57
Summary:
## Context
A React Native application can configure its RCTNetworking by initializing it with id<RCTURLRequestHandler> objects.
Therefore, RCTNetworking supports this initializer:
```
- (instancetype)initWithHandlersProvider:(NSArray<id<RCTURLRequestHandler>> * (^)(void))getHandlers
```
Right now, all id<RCTURLRequestHandler> are NativeModules. So, they need to be loaded using the Bridge/TurboModuleManager.
## Problem
The method [that constructs RCTNetworking](https://www.internalfb.com/code/fbsource/[6530647879a5e6d5edcfad029b39879c87e97bb3]/fbobjc/Apps/Wilde/FBReactModule2/FBReactModuleAPI/FBReactModuleAPI/FBReactModule.mm?lines=1471) is shared between bridge mode and bridgeless mode. So, the shared constructor needs to know what infra to use to load the request handlers: the TurboModuleManager, when called from a bridgeless context; the bridge, when called from a bridge context. There's no easy way to let this shared constructor know what context it's being called from. We could fork the constructor, but that's not very clean.
## Changes
In this refactor, RCTNetworking gives its _handlersProvider its RCTModuleRegistry. If the module was instantiated in bridgeless mode, RCTModuleRegistry will use the TurboModuleManager. If the module was instantiated in bridge mode, RCTModuleRegistry will use the bridge. Using RCTModuleRegistry allows the _handlersProvider to load id<RCTURLRequestHandler> from correct infra, in both contexts.
Changelog: [iOS][Changed] - Give RCTNetworking handler provider block RCTModuleRegistry
Reviewed By: PeteTheHeat
Differential Revision: D28013000
fbshipit-source-id: 956d660771ab18f5e7f24fcc28792f9a217146e7
Summary:
CocoaPods will display a "fatal: not a git repository" when these podspecs are consumed within Facebook's internal Mercurial repository due to the reliance on `git` to obtain the current commit hash.
In these cases, the podspec is being consumed locally and the commit hash is unnecessary.
The error is removed by avoiding the use of `git` if the current working directory is not a git repository (or any of the parent directories).
Changelog:
[Internal] [iOS] - Remove CocoaPods error within Facebook's repository
Reviewed By: fkgozali
Differential Revision: D27750974
fbshipit-source-id: 99159611c580baf5526f116948c5ff60e1c02e5c
Summary:
We're making the getTurboModule: method required for all classes that conform to RCTTurboModule.
Many of our ObjC-only and Cxx NativeModules don't implement this method. This diff implements a getTurboModule: method on all those modules that returns nullptr.
**Question:** Why is it fine to make ObjC-only NativeModules return nullptr from their getTurboModule: method?
- Because they're only accessed from ObjC, and should appear as null on the JavaScript side. Longer term, these NativeModules will also go away.
**Question:** Why is it fine to make Cxx NativeModules return nullptr from getTurboModule: method?
- Because after D27316872, the TurboModuleManager checks if the module is a CxxModule first. If it is, we do an early return, and never call the module's getTurboModule: method.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D27316871
fbshipit-source-id: bc693f2927ab3b0de24e6e9e7699390ec0f7d729
Summary:
Flow is changing the behavior of object types to no longer be valid supertypes of classes. This replaces object types when they appear as supertypes of classes to be interfaces to avoid errors when this change rolls out.
Changelog: [Internal]
Reviewed By: pieterv
Differential Revision: D27193522
fbshipit-source-id: c3e3fca8a4cacd90770a95b773ff2c659774b9a6
Summary:
ES Modules implicitly enable strict mode. Adding the "use strict" directive is, therefore, not required.
This diff removes all "use strict" directives from ES modules.
Changelog:
[Internal]
Reviewed By: motiz88
Differential Revision: D26172715
fbshipit-source-id: 57957bcbb672c4c3e62b1db633cf425c1c9d6430
Summary:
Refactors `RCTNeworking.ios.js` so that event registration does not get passed along to `NativeNetworkingIOS`. Instead, we go straight to `RCTDeviceEventEmitter` (which is what `NativeEventEmitter` ultimately does when `nativeModule` is not supplied).
This optimization reduces overhead of making network requests, and it is made possible because `NativeNetworkingIOS` does not actually do any meaningful work when `startObserving` is invoked.
Changelog:
[iOS][Removed] - Removed event methods except `addListener` from `Networking`
Reviewed By: lunaleaps
Differential Revision: D26137965
fbshipit-source-id: b6e0288689459ddb8ecf8d34dce6250d3b0ecb59
Summary:
Since `RCTNetworking` overrides init, it requires main queue setup. Native module infra currently throw a yellowbox if a module forgets it.
This diff fixes that.
{F361182429}
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D25962402
fbshipit-source-id: d847117cbfe0a191dc1882898711693c6fda68cd
Summary:
allow-large-files
Changelog: [iOS] Remove iOS10/tvOS10 suppport
Similar to D19265731 (674b591809) for iOS9.
I just ran this command:
`find . -type f -exec sed -i '' 's/{ :ios => "10.0" }/{ :ios => "11.0" }/' {} +`
and then updated pods
Reviewed By: fkgozali
Differential Revision: D25693227
fbshipit-source-id: 0073d57ecbb268c52d21962cef202316857bcbd2
Summary:
Adds types to Event Emitters and migrates the most relevant modules using them in `react-native`.
The most relevant file of this diff is `react-native/Libraries/vendor/emitter/__flowtests__/EventEmitter-flowtest.js` with the Flow tests showing and testing the behavior of the new types
Changelog: [Internal] Add types for Event Emitters and subclasses
Reviewed By: motiz88
Differential Revision: D25587936
fbshipit-source-id: feeb09f9ad15d383cdd82deaaaba0d12b94e868b
Summary:
Migrates all usages of `NativeEventEmitter` to `NativeEventEmitter<$FlowFixMe>`.
This prevents having to modify a very large number of files in the same change that adds support for typed events. It adds an unused typed parameter to `NativeEventEmitter` so we can change all usages to add `$FlowFixMe`.
Changelog: [Internal]
Reviewed By: nadiia
Differential Revision: D25575774
fbshipit-source-id: c7979e1502e980401d9c03456282eba333c1606d
Summary:
## Context
When you add/remove listeners from event emitters in JavaScript on iOS, we [call the NativeModule's addListener/removeListener methods](https://fburl.com/diffusion/4878jv6p). These addListener() and removeListener() methods [are implemented on the RCTEventEmitter class](https://fburl.com/diffusion/y913pqhy). All event emitters on iOS are subclasses of RCTEventEmitter.
The only purpose of calling RCTEventEmitter's addListener() and removeListener() methods is to call the [subclasses' startObservation, and stopObservation methods](https://fburl.com/diffusion/rpzyfppk), and [increment/decrement a listenerCount member variable](https://fburl.com/diffusion/ktl8if26) in RCTEventEmitter, which helps catch memory leaks.
RCTNetworking is a subclass of RCTEventEmitter, but it doesn't implement these startObserving/stopObserving methods. Since the [listenerCount is only used to show warnings](https://fburl.com/diffusion/i45lobil), in D24272560 (82187bfb6b), I disabled observation in RCTNetworking on the native side. Then in D24272663 (dabca52f77), I disabled RCTNetworking.addListener/removeListener NativeModule calls in JavaScript. This was gated via a QE/MC.
## Problem
The default initializer of RCTNetworking doesn't initialize with observation disabled. This broke antwerp when we shipped the experiment in D24272663 (dabca52f77). This diff fixes that problem.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D25671343
fbshipit-source-id: d9a8ba5324a23ade8f4b0bf2ec093f3e4fb494dc
Summary:
## Context
Every time we call RCTNetworking.sendRequest(), we [set up six event listeners inside XMLHttpRequest](https://fburl.com/diffusion/85k6ou5w) by calling RCTNetworking.addListener(). Seeing how RCTNetworking.addListener() is implemented, each call results in two async NativeModule call: [one to addListener()](https://fburl.com/diffusion/ng21jek6), and [another to removeEventListener()](https://fburl.com/diffusion/nua3y973).
For RCTNetworking, both of these NativeModule calls are unnecessary, as explained in D24272663 (dabca52f77)
> RCTNetworking.startObserving and RCTNetworking.stopObserving don't exist. The main purpose of RCTEventEmitter.addListener is to call these methods, and increment the _listeners counter, so that we can start dispatching events when _listeners > 0. In D24272560 (82187bfb6b), I made RCTEventEmitter dispatch events even when _listeners <= 0. This is sufficient for us to stop calling these two RCTNetworking methods entirely.
Therefore, this experiment gets rid of on average 6-8 NativeModule method calls for every network call we make in React Native on iOS.
Reviewed By: PeteTheHeat
Differential Revision: D25618704
fbshipit-source-id: 0da20475a0882ed737cf32de27f266fd2cd016af
Summary:
All NativeModules that used to use the bridge to require other NativeModules now require other NativeModules via the Venice-compatible RCTModuleRegistry abstraction. Therefore, we can safely get rid of synthesize bridge = _bridge from them.
## How did I generate this diff?
1. Search for all NativeModules that have `synthesize bridge =`
2. Remove the `synthesize bridge = _bridge` from each NativeModule, and if it doesn't contain `_bridge`, `setBridge:`, or `elf.bridge`, add it to this codemod.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25551295
fbshipit-source-id: 585d50ad55cb9ab083e430b07e1cf30e31f0d3c5
Summary:
All NativeModules that access the _bridge from self to require the Networking NativeModule now instead get the Networking NativeModule from the _moduleRegistry.
NOTE: xbgs .networking reveal any other usages. So, there won't be a manual migration diff associated with this codemod.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25499412
fbshipit-source-id: 7b0e33135c6c91ffc1e041ad3ab95f1346a8bc22
Summary:
This diff cleans up a bunch of code in `symbolicateStackTrace`. According to motiz88 all of it is dead code and I can confirm symbolication does not break with the changes applied.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D24585849
fbshipit-source-id: 5b2c76f56dbbbf27449ce1472cdd0271ed230c35
Summary:
RCTNetworking.startObserving and RCTNetworking.stopObserving don't exist. The main purpose of RCTEventEmitter.addListener is to call these methods, and increment the `_listeners` counter, so that we can start dispatching events when `_listeners > 0`. In D24272560, I made RCTEventEmitter dispatch events even when _listeners <= 0. This is sufficient for us to stop calling these two RCTNetworking methods entirely.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24272663
fbshipit-source-id: de9c968bc71e6e6d69a22b934644e6dfa3266b3f
Summary:
## Rationale
For every 1 call to RCTNetworking.sendRequest, we execute 6 calls to RCTNetworking.addListener. This is followed by at least one call to RCTNetworking.removeListeners. Aside from incrementing and decrementing the `_listeners` integer, these two methods accomplish nothing else: RCTNetworking doesn't implement the `startObserving` and `stopObserving` methods.
This diff makes RCTEventEmitter dispatch events without looking at the listeners integer. In the future, this will allow us to stop making these ~8 unnecessary NativeModule calls for every Network request we send.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24272560
fbshipit-source-id: 7996eba5abfa4669a89c43a3ffa536c0faa214a8
Summary:
This diff ended up being a bit more complicated than I anticipated, since the source files in `ReactInternal` were depending on `RCTEventDispatcher`. I made the following changes:
1. Make `RCTEventDispatcher` a `protocol`, keep it in `ReactInternal`.
2. Rename the `RCTEventDispatcher` NativeModule to `RCTEventDispatcherModule`, make it conform to the `RCTEventEmitter` `protocol`, and move it to `CoreModules`.
3. Where necessary, replace categories of `RCTEventDispatcher` with functions.
Changelog:
[iOS][Added] - Make RCTEventDispatcher TurboModule-comaptible
Reviewed By: fkgozali
Differential Revision: D18439488
fbshipit-source-id: b3da15c29459fddf884519f33b0c3b8c036b5539
Summary:
Refs: [0.62 release](https://reactnative.dev/blog/#moving-apple-tv-to-react-native-tvos), https://github.com/facebook/react-native/issues/28706, https://github.com/facebook/react-native/issues/28743, https://github.com/facebook/react-native/issues/29018
This PR removes most of the tvOS remnants in the code. Most of the changes are related to the tvOS platform removal from `.podspec` files, tvOS specific conditionals removal (Obj-C + JS) or tvOS CI/testing pipeline related code.
In addition to the changes listed above I have removed the deprecated `Platform.isTVOS` method. I'm not sure how `Platform.isTV` method is correlated with Android TV devices support which is technically not deprecated in the core so I left this method untouched for now.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
* **[Internal] [Removed]** - remove most of tvOS remnants from the code:
* `TVEventHandler`, `TVTouchable`, `RCTTVView`, `RCTTVRemoteHandler` and `RCTTVNavigationEventEmitter`
* **[Internal] [Removed]** - remove `TARGET_TV_OS` flag and all the usages
* **[iOS] [Removed]** - remove deprecated `Platform.isTVOS` method
* **[iOS] [Removed]** - remove deprecated and TV related props from View:
* `isTVSelectable`, `hasTVPreferredFocus` and `tvParallaxProperties`
* **[iOS] [Removed]** - remove `BackHandler` utility implementation
Pull Request resolved: https://github.com/facebook/react-native/pull/29407
Test Plan: Local tests (and iOS CI run) do not yield any errors, but I'm not sure how the CI pipeline would react to those changes. That is the reason why this PR is being posted as Draft. Some tweaks and code adjustment could be required.
Reviewed By: PeteTheHeat
Differential Revision: D22619441
Pulled By: shergin
fbshipit-source-id: 9aaf3840c5e8bd469c2cfcfa7c5b441ef71b30b6
Summary:
Since `dealloc` can be called from any thread, this would result `stopObserving` being called on a different thread/queue than the specified `methodQueue`. We specifically encountered this issue with a module needing the main queue having its `stopObserving` called on a background queue.
Changelog:
[iOS][Fixed] - Call [RCTEventEmitter stopObserving] on specified method queue
Reviewed By: RSNara
Differential Revision: D23821741
fbshipit-source-id: 693c3be6876f863da6dd214a829af2cc13a09c3f
Summary:
Microsoft’s RN for macOS fork supports the Hermes engine nowadays https://github.com/microsoft/react-native-macos/pull/473. As a longer term work item, we’ve started moving bits that are not invasive for iOS but _are_ a maintenance burden on us—mostly when merging—upstream. Seeing as this one is a recent addition, it seemed like a good candidate to start with.
As to the actual changes, these include:
* Sharing Android’s Hermes executor with the objc side of the codebase.
* Adding a CocoaPods subspec to build the Hermes inspector source and its dependencies (`Folly/Futures`, `libevent`).
* Adding the bits to the Xcode build phase script that creates the JS bundle for release builds to compile Hermes bytecode and source-maps…
* …coincidentally it turns out that the Xcode build phase script did _not_ by default output source-maps for iOS, which is now fixed too.
All of the Hermes bits are automatically enabled, on macOS, when providing the `hermes-engine-darwin` [npm package](https://www.npmjs.com/package/hermes-engine-darwin) and enabling the Hermes pods.
## Changelog
[General] [Added] - Upstream RN macOS Hermes integration bits
Pull Request resolved: https://github.com/facebook/react-native/pull/29748
Test Plan:
Building RNTester for iOS and Android still works as before.
To test the actual changes themselves, you’ll have to use the macOS target in RNTester in the macOS fork, or create a new application from `master`:
<img width="812" alt="Screenshot 2020-08-18 at 16 55 06" src="https://user-images.githubusercontent.com/2320/90547606-160f6480-e18c-11ea-9a98-edbbaa755800.png">
Reviewed By: TheSavior
Differential Revision: D23304618
Pulled By: fkgozali
fbshipit-source-id: 4ef0e0f60d909f3c59f9cfc87c667189df656a3b
Summary:
Replaces `fbjs/warning` call sites in React Native with `console.warn`. A few warnings will now log as warnings without the "Warning:" prefix.
Changelog:
[General][Changed] - Some warnings changed to use `console.warn` without the "Warning:" prefix.
Reviewed By: TheSavior, cpojer
Differential Revision: D22445946
fbshipit-source-id: 96b01e1bdee52b89ff3b808bc9d6cd494f6787f5
Summary:
Changelog: Fix [TypeError: Network request failed] on file upload
# Problem
In 3198009410 I made method `loadImageForURL` blocking and nil returning since it was no longer cancellable.
However inside `[RCTNetworkTask validateRequestToken]` was a logic counting on request token being non nil.
This diff removes this check and adds `nullable` to `[RCTImageURLLoader loadImageForURL]` making it explicit.
Reviewed By: PeteTheHeat
Differential Revision: D22767174
fbshipit-source-id: 04d5562e381912233b9c14e8156cbf145288f063
Summary:
## Problem
For some reason, D20831545 broke the `use_frameworks!` build of RNTester.
## Building RNTester
```
pushd ~/fbsource/xplat/js/react-native-github/RNTester && USE_FRAMEWORKS=1 pod install && open RNTesterPods.xcworkspace && popd;
```
## Error
I built RNTester locally, and the error was this:
```
Undefined symbols for architecture x86_64:
"facebook::jsi::HostObject::set(facebook::jsi::Runtime&, facebook::jsi::PropNameID const&, facebook::jsi::Value const&)", referenced from:
vtable for facebook::react::ObjCTurboModule in RCTImageEditingManager.o
vtable for facebook::react::ObjCTurboModule in RCTImageLoader.o
vtable for facebook::react::ObjCTurboModule in RCTImageStoreManager.o
"facebook::jsi::HostObject::getPropertyNames(facebook::jsi::Runtime&)", referenced from:
vtable for facebook::react::ObjCTurboModule in RCTImageEditingManager.o
vtable for facebook::react::ObjCTurboModule in RCTImageLoader.o
vtable for facebook::react::ObjCTurboModule in RCTImageStoreManager.o
ld: symbol(s) not found for architecture x86_64
```
## Fix
It looked like libraries that depend on "ReactCommon/turbomodule/core" weren't linking to JSI correctly. So, I modified all such Podspecs to also depend on "React-jsi":
```
arc rfr ' s.dependency "ReactCommon/turbomodule/core", version' ' s.dependency "ReactCommon/turbomodule/core", version\n s.dependency "React-jsi", version'
```
This seemed to do the trick. In buck, we'd fix this problem using exported_dependencies. I skimmed through cocoapods, and couldn't find such a configuration option there. So, I guess this will have to do?
Changelog:
[iOS][Fixed] - Fix Cocoapods builds of RNTester
Reviewed By: fkgozali, hramos
Differential Revision: D20905465
fbshipit-source-id: 60218c8274ec165752a428f2a7a9a546607c8fec
Summary:
This gets us on the latest Prettier 2.x:
https://prettier.io/blog/2020/03/21/2.0.0.html
Notably, this adds support for TypeScript 3.8,
which introduces new syntax, such as `import type`.
Reviewed By: zertosh
Differential Revision: D20636268
fbshipit-source-id: fca5833d003804333a05ba16325bbbe0e06d6c8a
Summary:
We recently updated React Native's docs site to have its own domain reactnative.dev and needed to update the URLs in the source code
CHANGELOG:
[INTERNAL]
Reviewed By: hramos
Differential Revision: D20072842
fbshipit-source-id: 1970d9214c872a6e7abf697d99f8f5360b3b308e
Summary:
ChangeLog: [Both] Adds perf markers for `XMLHttpRequest`s
Makes it easier to see JS-based network operations in performance traces.
Reviewed By: zackargyle
Differential Revision: D19903143
fbshipit-source-id: c5ce60163569e003830d8079cb2b580469d5bd5d
Summary:
In `XMLHttpRequest`, if the responseType is `Blob`, but the response is an empty string, we return `null` from `XMLHttpRequest.prototype.response()`. Instead, we should return an empty Blob. This is the behaviour on the web. To demonstrate, run the following HTTP server with Node:
## server.js
```
const http = require('http');
const server = http.createServer();
server.on('request', (request, response) => {
if (request.url.includes('img.png')) {
console.log('sending image');
response.end('');
return;
}
response.end('Hello World!');
});
server.listen('9000');
```
Then, open up a web browser to `http://localhost:9000`, and type the following in the console:
```
var oReq = new XMLHttpRequest();
oReq.open('GET', 'http://localhost:9000/img.png', true);
oReq.responseType = 'blob';
oReq.onload = function(oEvent) {
var blob = oReq.response;
console.warn(blob);
};
oReq.onerror = function(error) {
console.warn('Error!');
};
oReq.send();
```
This warns:
```
Blob {size: 0, type: "text/xml"}
```
Changelog:
[Both][Fixed] - [RN][XMLHttpRequest] Transform empty responses into empty Blobs
Reviewed By: sahrens
Differential Revision: D19500607
fbshipit-source-id: ec35e534b32a507c8a94a29e955b7bc4c62902a0
Summary:
It can be a pain to debug slow network issues, especially with the iOS simulator which doesn't have a network link conditioner. This makes it really easy and predictable by simply adding a `setTimeout` around calling `sendRequest`.
Changelog:
[General] [Added] - DEBUG_NETWORK_SEND_DELAY can be used to simulate slow network.
Reviewed By: PeteTheHeat
Differential Revision: D19236911
fbshipit-source-id: 14762c7e0c6408a8364aa569c482729a7a1fe740
Evan Yeung
Kudo Chien
Peter Argany
Arthur Lee
Håkon Knutzen
Daniel Sainati
Scott Kyle
Ramanpreet Nara
Héctor Ramos
Rubén Norte
Luna Wei
Micha Reiser
Tim Yung
Javier Fraire
Christoph Nakazawa
Lulu Wu
simek
Eloy Durán
Samuel Susla
Michael Bolin
Rachel Nabors
Spencer Ahrens
