Summary:
I'm going to be flipping the default from autoglob on `fb_apple_library` to `True`. This prepares the target so that there are no behavior changes.
## Changelog: [Internal]
Reviewed By: natestedman
Differential Revision: D29769275
fbshipit-source-id: 7ac04f8a8f7e41ce8d43a81b25ebd063b3a9f3de
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:
When you reload React Native surfaces via the CMD + OPT + R keystroke, this is the actual code that executes:
https://www.internalfb.com/code/fbsource/[9c79fc6a17b7738b391a605412abf1cb15ef8ea1]/xplat/js/react-native-github/React/CoreModules/RCTDevSettings.mm?lines=172-175%2C179-183
It's only executed when RCTDevSettings is instantiated by the bridge. So, if only bridgeless surfaces are loaded, then CMD + OPT + R doesn't work.
## Fix
In this diff, I ensure that
1. We set up the reload listener when RCTDevSettings is *first* instantiated
2. We clear the reload listener when all instances of RCTDevSettings are invalidated.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D29437952
fbshipit-source-id: 9f2ff8340575c0ed881df26249433b2075bbd2ac
Summary:
The Facebook app can have both bridge and bridgeless surface. Each type of surface has its own DevMenu. It's important to specify which DevMenu is being rendered, because not doing so can make for some confusing/frustrating devx (e.g: the bridgeless dev menu shows up for bridge surfaces: https://pxl.cl/1L1m7).
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D29439980
fbshipit-source-id: 24de1e6b44e5315c0cee0684d0db5df31514d3e2
Summary:
This migrates all ObjC NativeModule setBridge: calls to the bridge compatible initialize: call. I filtered out ViewManagers.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D28595520
fbshipit-source-id: b0e5dd681fb3563894f1aa3da1728f0c694f04bb
Summary:
When we initialize RCTDevLoadingView, we dispatch_sync to the main thread. There isn't anything in the NativeModule that requires us to initialize it on the main thread. So, this diff toggles requiresMainQueueSetup to NO. This should mitigate this prefetch-related deadlock: T90970812. Please read the task comments for the rationale.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D28490715
fbshipit-source-id: 7efceb392ec9e0cabe7f7cd8867cf4b07f8fff19
Summary:
This diff removes all synthesize invokeJS = _invokeJS calls, and instead funnels them through synthesize callableJSModules = _callableJSModules. Now, all these NativeModules shouldn't have different branching in bridgeless mode vs bridge mode.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D28395445
fbshipit-source-id: 41a58d54c60be55e6bf5031e5417728f5eb6285c
Summary:
When RCTDevLoadingView is created, it checks to see if the bridge is loading. If so, displays the loading banner with the bundleURL. This logic is better placed in the bridge, because the bridge is also responsible for updating progress on the DevLoadingView.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D28301524
fbshipit-source-id: fb6c259b546d8cd9e08568a88c7046d06c70ed6f
Summary:
RCTJSInvokerModule invokeJS can do the work done by setInvokeJSWithModuleDotMethod. Therefore, this diff reduces the surface area of Venice, and gets rid of setInvokeJSWithModuleDotMethod.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D28232947
fbshipit-source-id: aa0d8497a1e0fba29109ca86a39de5d9e5b10c9c
Summary:
This diff migrated RCTDevSettings to the RCTBundleManager, which works both in bridge/bridgeless mode. RCTDevSettings is the last TurboModule that synthesizes the bundleURL. So, after this diff, we can get rid of the RCTBundleHolderModule protocol.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D28232320
fbshipit-source-id: ab53278fea0ea7e025cf748be62bc5d610593e7f
Summary:
Changelog: Fix main thread access to UIKit in RCTRedBox
{F611784226}
Xcode's main thread checker complains about this during reload. it is not needed to set `dataSource` and `delegate` to nil because the table view is about to be destroyed.
Reviewed By: mdvacca
Differential Revision: D28089039
fbshipit-source-id: 13b62cafb4790fc15b5a5dde131d4ae64bd97c82
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:
All NativeModules/TurboModules can use the following Venice-compatible API instead:
```
synthesize moduleRegistry = _moduleRegistry
```
In bridge mode, it'll look up the module via the TurboModule system/bridge.
In bridgeless mode, it'll look up the module via the TurboModule system.
Therefore, there's no need to support this API.
Changelog: [iOS][Removed] - Delete synthesize turboModuleRegistry API in RCTTurboModule
Reviewed By: fkgozali
Differential Revision: D28070740
fbshipit-source-id: d2c8285fd4c05b67fb03ce82217bf6ddfd1dd685
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:
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:
`RCTDevSettings` uses the API `bridge.isInspectable` to understand if the runtime can be debugged. In bridgeless mode, let's use `RuntimeExecutor` to check the same property.
Changelog: [Internal]
Reviewed By: p-sun
Differential Revision: D27095935
fbshipit-source-id: 93785774b175bd7da17269e1590b5d92eba2b0cf
Summary:
Live reloading has been deprecated in favor of fast refresh for years, this diff removes remaining references to it.
Changelog: [iOS] Delete deprecated "live reloading" setting
Reviewed By: fkgozali
Differential Revision: D26983596
fbshipit-source-id: c7f86e7ec511f80e53659bccd8f40ac4f0cac27c
Summary:
Changelog: [Internal]
This moves enabling/disabling fast refresh off of `bridge.enqueueJSCall` in bridgeless mode.
Reviewed By: sammy-SC
Differential Revision: D26290378
fbshipit-source-id: ed8a3389b9812cedf7181971656dacd98ff7ecfd
Summary:
Changelog: [Internal]
This diff allows `RCTDevSettings` to access bundleURL directly instead of relying on the bridge.
Reviewed By: RSNara
Differential Revision: D26289592
fbshipit-source-id: e22e583e51323bfe66f6e424d9f47edf71b1ed9f
Summary:
Changelog: [Internal]
This removes a couple dependencies on bridge in dev menu native module. So far reloading works, will get inspector and other options working in follow ups.
Reviewed By: sammy-SC
Differential Revision: D26240391
fbshipit-source-id: 7c9d585f4efa6cc9db995ef8a33865831bc8d526
Summary:
Live reload was removed as a user facing feature in 2019 in favour of fast refresh. The native code was left in case "automation" relied on it. I'm quite sure no automation is using this dev feature. Remember, the dev feature made it so that hitting save in a text editor auto reloaded in metro.
Cleanup the native implementation.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D26239628
fbshipit-source-id: 7f61c7204727bb2d739600a459f69c72842265c5
Summary:
IIUC `isDebuggingRemotely` will never be set when `isDeviceDebuggingAvailable` is true. This was just a failsafe so that noone was trapped in an intermediate state.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D26239570
fbshipit-source-id: 8db6b022a0ea581216a1fa97b9d41f5ab6160562
Summary:
In bridegless mode, `setBridge` is never called on native modules. This diff refactors out some setup logic into the module's init method.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D26211620
fbshipit-source-id: 7a9910198852dea5ac679762aa93dfea6fc47d70
Summary: Changelog: [iOS] Only show Dev Menu on shake if RN view is visible
Reviewed By: fkgozali
Differential Revision: D26138659
fbshipit-source-id: e2db287728675c7ead5fcbf569ed591638e2187e
Summary:
## Description
Suppose this was the codegen declaration before:
```
rn_library(
name = "FooModule",
native_module_spec_name = "FBReactNativeSpec",
codegen_modules = True,
# ...
)
```
Previously, this would generate the following BUCK targets:
- generated_objcpp_modules-FooModuleApple
- generated_java_modules-FooModuleAndroid
- generated_java_modules-FooModule-jniAndroid
## Changes
We will now generate:
- FBReactNativeSpecApple
- FBReactNativeSpecAndroid
- FBReactNativeSpec-jniAndroid
This matches the naming scheme of the old codegen.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D25680224
fbshipit-source-id: 617ac18fd915f3277f6bd98072d147f20fb193e5
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:
Ran `xbgs .accibilityManager`, and found all the NativeModules that used the bridge to access AccessibilityManager. Then, I migrated them to use RCTModuleRegistry.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25504726
fbshipit-source-id: fcfb1fffbeedc136ee160d043949d9859300b1e3
Summary:
Ran `xbgs .redBox`, and found all the NativeModules that used the bridge to access RedBox. Then, I migrated them to use RCTModuleRegistry.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D25507829
fbshipit-source-id: 91033ca4c57d5be5e8e6fa904b636960ec12c584
Summary:
Ran `xbgs .devSettings`, and found all the NativeModules that used the bridge to access DevSettings. Then, I migrated them to use RCTModuleRegistry.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25503402
fbshipit-source-id: 26afc45cd1bc63d5de99ea331e7b2949b66be7ce
Summary:
All NativeModules that access the _bridge from self to require the DevSettings NativeModule now instead get the DevSettings NativeModule from the _moduleRegistry.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25503289
fbshipit-source-id: ebd1fd45d40aca37c0ead83bbaab59fa99d45044
Summary:
Ran xbgs `.devMenu`, and found all the NativeModules that used the bridge to access DevMenu. Then, I migrated them to use RCTModuleRegistry.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25499960
fbshipit-source-id: 70478616d44808f3788dd0b194da155db0877db9
Summary:
This is an extension of D25449795. I searched for all usages of .eventDispatcher within NativeModules, and migrated them all to the Venice-compatible RCTModuleRegistry API.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25473844
fbshipit-source-id: 2b8deec236e019f3adfb59fadd745c249ff822f4
Summary:
All NativeModules that use the bridge to require the eventDispatcher are now instead using the RCTModuleRegistry I introduced in D25412847 (https://github.com/facebook/react-native/commit/0ed81b28d3d786ea3b1cf0b932a008ef1f806ec4).
## What does this codemod do?
For all ObjC files that contain `synthesize bridge = _bridge`, migrate calls that access the React Native bridge from `self`, and use it to load the event dispatcher.
**Thoughts on Codemod Safety:** If we can access the bridge from self, then that means that if we synthesize the module registry, we can access the module registry from self. Therefore, this codemod is safe.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25449795
fbshipit-source-id: 2f7235d14659e73d673ae08763dc2cccdde55a19
Summary:
`RCTAlertController` creates a new window, and presents itself in that window.
RCTAlertController strongly retains the window, and the window strongly retains RCTAlertController when presenting it.
This adds a new method to break that cycle once alert is dismissed.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D25312413
fbshipit-source-id: e4048922aa697eb42c4c149827bac61bc7bc5528
Jason Safaiyeh
Dustin Shahidehpour
Kudo Chien
Ramanpreet Nara
Samuel Susla
Peter Argany
Scott Kyle
Héctor Ramos
Andres Suarez
Aditya Kumar
generatedunixname89002005325676