Summary:
Bumping RTC-Folly version used to address CVE-2022-24440.
## 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
-->
[General][Security] - Bump RTC-Folly to 2021-07-22
Pull Request resolved: https://github.com/facebook/react-native/pull/33841
Reviewed By: Andjeliko, philIip
Differential Revision: D36425598
Pulled By: cortinico
fbshipit-source-id: d38c5f020dbecf794b10f12ed2da30e1825071af
Summary:
Changelog:
[iOS][Fixed][Internal] - Protect handlers in RCTNetworking with mutex even if RCTNetworking has been deallocated
# The Logview
We get this error in LogView: `Unhandled JS Exception: Error: Exception in HostFunction: mutex lock failed: Invalid argument`, which is an C++ std::error. "This typically happens when .lock() is called on a mutex that is not yet constructed, or has already been destructed."
# Hypothesis of issue
The LogView says the line that throws this softerror is [RCTNetworking.ios.js](https://github.com/facebook/react-native/blob/8bd3edec88148d0ab1f225d2119435681fbbba33/Libraries/Network/RCTNetworking.ios.js#L87).
Inside RCTNetworking, there's only [one mutex and only one line where is is being used](https://github.com/facebook/react-native/blob/8bd3edec88148d0ab1f225d2119435681fbbba33/Libraries/Network/RCTNetworking.mm#L207-L215
), to protect the _handlers array.
My guess is that RCTNetworking was deallocated, which made `_handlersLock` nil, so it resulted in this error when we tried to lock it.
# This diff
* Add `std::lock_guard<std::mutex> lock(_handlersLock);` to `invalidate()`
* Move `_handlersLock` logic to its own method instead of using a lambda. If `self` is being deallocated, I would guess that this method (`[self prioritizedHandlers]`) would return nil.
Referencing this for correct ways to use lock_guard with mutex: https://devblogs.microsoft.com/oldnewthing/20210709-00/?p=105425
Reviewed By: fkgozali
Differential Revision: D36886233
fbshipit-source-id: 60246f4d9bbc1d834497e4fb8a61d9c0e9623510
Summary:
Changelog:
[Internal][Changed] - Remove babel plugins from jest preprocessor which are part of preset metro-react-native-babel-preset
Transformer metro-react-native-babel-transformer has preset metro-react-native-babel-preset which has necessary plugins to transpile the source. So we don’t need to pass it again in the preprocessor.
As part of the change, updated one test to use strict mode since metro-react-native-babel-preset has strictMode is set to false.
Reviewed By: motiz88
Differential Revision: D34868961
fbshipit-source-id: 71678f1ee6f1b5ebf9a0c6fd2d6444a61d7583ac
Summary:
We are working on making the empty object literal `{}` have the type `{}` - i.e. exact empty object - rather than being unsealed.
Making this change exposes a variety of errors. We can prevent these errors by annotating what we want the type of the empty object to be.
Reduces Xplat error diff to 2.3k
- Announcement: [post](https://fb.workplace.com/groups/flowlang/posts/903386663600331)
- Support group: [Flow Support](https://fb.workplace.com/groups/flow)
drop-conflicts
Format:
```
arc f
```
Sort imports
```
hg l -n | xargs js1 lint --fix --rule 'fb-tools/sort-requires'
```
Changelog: [Internal]
Reviewed By: samwgoldman
Differential Revision: D36086696
fbshipit-source-id: 90447279f2e6e38f44189b74ec0297719f7adf58
Summary:
The getAll() method of the [FormData](https://developer.mozilla.org/en-US/docs/Web/API/FormData) interface returns all the values associated with a given key from within a FormData object.
## Changelog
[General] [Added] - Add getAll function to FormData class for getting all parts containing that key. This is also available in web API.
Pull Request resolved: https://github.com/facebook/react-native/pull/32444
Test Plan: New test added in FormData-test.js
Reviewed By: lunaleaps
Differential Revision: D31798633
Pulled By: cortinico
fbshipit-source-id: ef29bb54e930532a671adbe707be8d1a64ff0d82
Summary:
The Array appended to FormData must be transmitted in the form of a string.
However, it is treated as a file object and transmitted, because `typeof Array` is `'object'` too
In network
```js
form.append('array_name', ['a', 'b', 'c'])
// Browser
// Content-Disposition: form-data; name='array_name';
// a,b,c
// ReactNative
// Content-Disposition: form-data; name='array_name';
//
```
## Changelog
[General] [Fixed] - The Array appended to FormData is transmitted as a string
Pull Request resolved: https://github.com/facebook/react-native/pull/32815
Test Plan: Added test case
Reviewed By: lunaleaps
Differential Revision: D33369594
Pulled By: charlesbdudley
fbshipit-source-id: 0b5219a2c9f73cf16665dc417cceb4481428ad4e
Summary:
alternative solution for https://github.com/facebook/react-native/issues/33379
> when `use_frameworks!` is on, there are errors like:
> ```
> 'FBReactNativeSpec/FBReactNativeSpec.h' file not found
> #import <FBReactNativeSpec/FBReactNativeSpec.h>
> ```
> this error may come from from https://github.com/facebook/react-native/commit/f7e4c07c84b6 regression.
>
> when `use_frameworks!` is on, xcode will search headers from framework directories, the correct imports would be `#import <React_Codegen/FBReactNativeSpec/FBReactNativeSpec.h>` (xcode will transform dash to underscore, so it is `React_Codegen` but not `React-Codegen`). in the other hand, when `use_frameworks!` is off, the correct import is `#import <React-Codegen/FBReactNativeSpec/FBReactNativeSpec.h>`.
>
>
> this fix is specific for old architecture (fabric is off).
>
> when fabric is on, there are other errors from duplicated headers when copying to build folder. [the reason is that framework build would try to flatten headers](https://mkonrad.net/2015/03/29/xcode-static-libraries-preserving-header-directory-structure.html). we have `primitives.h` in different folders and they would be flattened into `React_Fabric.framework/Headers`. to be honest, i don't know how to deal with the problem in the meantime, maybe subspecs are not enough, we should separate them from subspecs to dedicated podspecs so that we can have these targets as different frameworks.
in this alternative fix, i try to add `React-Codegen/React_Codegen.framework/Headers` into header search paths and make original `#import <FBReactNativeSpec/FBReactNativeSpec.h>` reachable.
[this change](https://github.com/facebook/react-native/commit/7a0398c331f22abc619a64b444ec7153357b0a30) in the pr is just a workaround to solve breaking in latest main branch and this is not important to the `use_frameworks!` fix at all. this breaking was coming from https://github.com/facebook/react-native/commit/180495159517dc0bfa103621e5ff62fc04cb3c8b.
## Changelog
[iOS] [Fixed] - Fix iOS build error when Podfile `use_frameworks!` is on and Fabric is off
Pull Request resolved: https://github.com/facebook/react-native/pull/33409
Test Plan:
verify with rn-tester
1. change `fabric_enabled` to false in `packages/rn-tester/Podfile`
2. `USE_FRAMEWORKS=1 pod install`
3. build rn-tester in xcode
Reviewed By: dmitryrykun
Differential Revision: D34817041
Pulled By: cortinico
fbshipit-source-id: 4d1a610e99a807793eb3f64461e0d735c0a9ca9c
Summary:
Flow currently allows duplicate members on classes. At runtime the "last" member wins out and all previous values for the member are discarded.
This diff manually removes duplicate members, and fixes resulting flow errors by converting methods to arrow function properties.
Reviewed By: pieterv
Differential Revision: D33664966
fbshipit-source-id: 0f712ac96af4df593c0918fcbadd70624ddde4a6
Summary:
In this diff, it moves the codegen output location out of node_modules and to build/generated/ios folder.
A temp pod spec will be created so that those files will be included in the Xcode project.
Changelog: [Internal]
Reviewed By: hramos, cortinico
Differential Revision: D31809012
fbshipit-source-id: ba1c884c8024306ba0fd2102837b7dbebc6e18ac
Summary:
As per the XMLHttpRequest specification [1], getAllResponseHeaders() should return a string of headers with lowercased names and sorted by their uppercase representation, with each header ending with '\r\n'.
[1] https://xhr.spec.whatwg.org/#the-getallresponseheaders()-method
## Changelog
[General] [Changed] XMLHttpRequest.getAllResponseHeaders() now returns headers with names lowercased and sorted in ascending order, as per specification
Pull Request resolved: https://github.com/facebook/react-native/pull/32363
Test Plan:
Test derived from Web Platform Test repository:
https://github.com/web-platform-tests/wpt/tree/master/xhr
Reviewed By: yungsters
Differential Revision: D31626217
Pulled By: sota000
fbshipit-source-id: 299d005facbe1c15b8cda5eed6750db75addca80
Summary:
Folly now depends on libc++abi. This solves linker error for RCT-Folly.podspec like this:
```
Undefined symbols for architecture arm64:
"___cxa_increment_exception_refcount", referenced from:
folly::exception_ptr_get_type(std::exception_ptr const&) in libRCT-Folly.a(Exception.o)
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
See https://github.com/react-native-community/releases/issues/251
Note: RNTester was not affected by this bug for some reason, so the only way to verify is via the new app generated via `npx react-native init`.
Changelog: [Fixed][iOS] Unbreak Folly linker error
Reviewed By: lunaleaps
Differential Revision: D30950944
fbshipit-source-id: 3eb146e23faa308a02363761d08849d6801e21ca
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:
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](https://github.com/facebook/react-native/blob/4c5182c1cc8bafb15490adf602c87cb5bf289ffd/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 (https://github.com/facebook/react-native/commit/d0c8cb12f21604fd9730e275a52816d7fd00a826)-9164-4925-9025-1A76C0D9 (https://github.com/facebook/react-native/commit/1946aee3d9696384d38890269ea705cafd472827)F0F5/data/Containers/Bundle/Application/B1E8A764-6221-4EA9-BE9A-2CB1699FD218 (https://github.com/facebook/react-native/commit/1c92b1cff623ea3f3b78238b146ab001626ef305)/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 (https://github.com/facebook/react-native/commit/674b591809cd1275b5f1c4d203c2f0ec52303396) 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
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 (https://github.com/facebook/react-native/commit/dabca52f77799bcdedb6b0ec44b1f6297483a46d)
> 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 (https://github.com/facebook/react-native/commit/82187bfb6b54fdffc5dadaa56e8bf97d2209708a), 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
Tim Yung
Rujin Cao
Pieter Vanderwerff
Luis Santana
Paige Sun
Deepak Jacob
George Zahariev
matinzd
bang9
Phillip Pan
Kudo Chien
Samuel Susla
Brad Zacher
Andres Suarez
Tim Yung
Sota Ogo
Andrew Scherkus
Kevin Gozali
Evan Yeung
Peter Argany
Arthur Lee
Håkon Knutzen
Daniel Sainati
Scott Kyle
Ramanpreet Nara
Héctor Ramos
Rubén Norte
Luna Wei
Micha Reiser
Javier Fraire
Christoph Nakazawa
Lulu Wu
simek