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:
This should be a noop. It just makes writing codemods easier.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25442218
fbshipit-source-id: dba0c35a6f566e83ed5b7142075fff6929efeada
Summary:
This commit:
* Generate Fabric component Java files along side Java NativeModule specs, when `USE_FABRIC=1` is set
* Adjust the component codegen to place output files in a subdir based on package name
* Adjust existing Buck targets to filter the right nativemodule vs component java files (this avoids duplicated symbols)
* Compiles the Java output during build time on RNTester/ReactAndroid (Gradle)
Not in this commit:
* Fabric C++ files
* Removing checked-in generated component files.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25416614
fbshipit-source-id: fd670ead2198c9b5a65812c692b7aed9f3d7cd58
Summary:
Changelog: [internal]
In D25386708 (https://github.com/facebook/react-native/commit/408bcdeedbc89cc9b90de73684d3f691b8e2e724) `synthesize bridge` was removed. But two modules actually depend on this.
`RCTFileReaderModule` and `VerseThreadView` which both use it.
Reviewed By: RSNara
Differential Revision: D25423574
fbshipit-source-id: daf95d9b27841cf8d205d8ea2666d5aa69a6d720
Summary:
This is a codemod. All these NativeModules demand access to the bridge. However, they don't use it.
Changelog: [Internal]
Reviewed By: PeteTheHeat, RoelCastano
Differential Revision: D25386708
fbshipit-source-id: f05f4777d2527e96e53581e7ac58f6be47411dce
Summary:
As part of the initialization of Native View configs, the PaperUIManager.getViewManagerConfig() method calls the native side to lazy initialize iOS Native components. This is necessaary to make ensure that native classes are loaded and initialized before a view is created.
Note that this requirement is only necessary when Fabric is disabled.
As part of JS ViewConfigs, we removed the native call to lazy initialize iOS native components. This causes a crash during the creation of NativeViews when JS ViewConfigs are enabled and Fabric is disabled. The rootcase of the exception is that native classes are not properly initialized when the createView method is executed in iOS.
This diff forces the lazy initialization of iOS Native components when JS View configs are enabled and Fabric is disabled. This new mechanism is executed as part of the creation of views and it's ONLY going to be executed when the user navigates to a NON-FABRIC screen, JS ViewConfigs are enabled and the component is not initialized yet.
The extra cost should be minimal or zero.
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D25387014
fbshipit-source-id: fe3bc42f803a805192b419bfb4b7a6b5b1b71b60
Summary:
UserFlow API now takes configuration parameter, which is required. It contains of 2 arguments:
* triggerSource
* cancelOnBackround
Reviewed By: swillard13
Differential Revision: D25094721
fbshipit-source-id: 64a468c2168265ade9f8d4cea4beb911637544fa
Summary:
this diff fixes the next error:
```
'RCTImageView' has a view config that does not match native. 'validAttributes' is missing: internal_analyticTag
in RCTImageView (at Image.ios.js:149)
in ImageAnalyticsTagContext.Consumer (at Image.ios.js:146)
in Image (at TintedIcon.js:55)
in TintedIcon (at TetraIcon.js:98)
in TetraIcon (at FDSCheckbox.js:67)
in FDSCheckbox (at TetraListCell.js:820)
in TetraAddOnSecondary (at TetraListCell.js:576)
in TetraPressable (at TetraListCell.js:603)
in TetraListCell (created by TetraListCell)
in TetraListCell (at RNInternalSettingsUnit.js:35)
in TetraList (at RNInternalSettingsUnit.js:32)
in RNInternalSettingsUnit (at RNInternalSettingsDeveloperModeUnit.new.js:73)
in RNInternalSettingsDeveloperModeUnit (at RNInternalSettingsSurface.js:79)
in RNInternalSettingsSurface (at withDefaultErrorBoundary.js:30)
in DefaultError(React.lazy(RNInternalSettingsSurfaceForFacebook)) (at renderApplication.js:47)
```
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D25313414
fbshipit-source-id: ab951d25ac6a80809a2977c80ff059f667cc5595
Summary: Changelog: [Internal] backout change dispatching main queue before using it
Reviewed By: shergin
Differential Revision: D25319046
fbshipit-source-id: 4f8952e577cfd9033fb2c2248b9b056a0d468b5d
Summary:
Move the codegen invocation out of Podfiles and into the FBReactNativeSpec Pod itself. With this change, developers do not need to modify their existing project's Podfiles, and yet the codegen will be integrated into their projects automatically by way of the FBReactNativeSpec Pod.
This is accomplished in part by injecting a script build phase into the Pods Xcode project that is generated by CocoaPods. The build phase will save the output of the codegen script to a log in the derived files directory. The codegen will be executed if the codegen log file is not present, or if the contents of the Libraries directory has changed.
The codegen will thus be invoked in these situations:
**RNTester:**
* When `packages/rn-tester/RNTesterPods.xcworkspace` is built, if the codegen output logfile is not present or if the input files have changed.
**OSS React Native apps:**
* When `ios/AwesomeProject.xcworkspace` is built, if the codegen output file is not present or if the input files have changed. Normally, this should not happen, as we do not expect folks to update the contents of `node_modules/react-native/Libraries`.
Pull Request resolved: https://github.com/facebook/react-native/pull/30449
Changelog: [Internal] - Moved codegen invocation out of Podfile and into FBReactNativeSpec Pod
Reviewed By: fkgozali
Differential Revision: D25138896
fbshipit-source-id: 4779f822459cea2c30fd544eee19a49e8d80153d
Summary:
As titled - attempt to mitigate a JS error on iOS while we work on getting JS view configs. It seems like this happens when the bridge is invalid.
Changelog: [Fixed][iOS] Don't throw an error if the UIManager returns null when fetching a view config
Reviewed By: kacieb
Differential Revision: D25247203
fbshipit-source-id: e2003f99b818f9657c60ff95b266be74fe18a94b
Summary:
Migrates `View` to use `NativeComponentRegistry`, which enables configuring it to avoid reflection by using a static `ViewConfig`.
Changelog:
[Internal]
Reviewed By: JoshuaGross
Differential Revision: D25136054
fbshipit-source-id: f2abda1105bd2a8b396db6f1a640430b62bbcdaf
Summary: Changelog: [Internal] `self.component` is main thread affined so we need to dispatch to main queue before using it.
Reviewed By: shergin
Differential Revision: D25163182
fbshipit-source-id: a7da0324982354215e0ccb47615f7f121200f12a
Summary:
Creates `NativeComponentRegistry.getWithFallback_DEPRECATED`. This is deprecated from inception because it exists only to support a pattern that should not be necessary.
For any given `NativeX` component, the JavaScript module that calls `NativeComponentRegistry.get('NativeX', …)` should only exist in the JavaScript bundle if the native binary actually supports that native component.
But in today's transitional state of the world, there are JavaScript modules that use `UIManager.getViewManagerConfig('NativeX')` as a means of feature detection.
The purpose of `NativeComponentRegistry.getWithFallback_DEPRECATED` is to bridge this transitional gap. Component should migrate toward initializing the `NativeComponentRegistry` with a runtime configuration provider that enumerates all supported native components. If the native component is not supported, it should return null.
Changelog:
[Internal]
Reviewed By: fkgozali
Differential Revision: D25109988
fbshipit-source-id: 76f7077904594ca63495d8338905c43712ea02e0
Summary:
Migrates `ImageView` to use `NativeComponentRegistry`, which enables configuring it to avoid reflection by using a static `ViewConfig`.
Changelog:
[Internal]
Reviewed By: JoshuaGross
Differential Revision: D25104446
fbshipit-source-id: dd01bf01ead94ca6632b2653b45becf408953bcf
Summary:
There may be assumptions that `Native*.js` contains TurboModule. In order to avoid introducing unplanned breaking changes (especially right before the holidays), roll this back for now.
In doing so, I also realized that I forgot to migrate over `ScrollContentViewNativeComponent`. This does that, too.
Changelog:
[Internal]
Reviewed By: RSNara
Differential Revision: D25129324
fbshipit-source-id: 343c4b800969dab91f7cd9f2bf253788c94d38e6
Summary:
The Flow team has been building a new implementation of the system that typechecks the body of generic functions and classes. This system is more sound than the previous approach and detects errors that were uncaught previously. This diff turns on the new generic system by setting generate_tests=false in the .flowconfig, and suppresses newly discovered errors.
This diff modifies and re-signs some generated modules, because syncing from www pulled in a ton of other changes that have runtime differences, and I'm not equipped to verify that the changes are safe to land.
Changelog: [Internal]
Reviewed By: panagosg7
Differential Revision: D24801184
fbshipit-source-id: bb31fe4c5a4107d183649b436a548df5ff42e217
Summary:
Migrates `ScrollView` (and its related native components) to use `NativeComponentRegistry`. This will enable it to be configured using experiments to conditionally use the native `ViewConfig` or verify the static `ViewConfig`.
This also cleans up a bunch of the modules and types related to defining the native `ScrollView` component.
This also proposes adopting the same module naming protocol was has been adopted for TurboModules (i.e. `NativeScrollView` instead of `ScrollViewNativeComponent`).
Changelog:
[Internal]
Reviewed By: JoshuaGross
Differential Revision: D25098530
fbshipit-source-id: ff1394bfac023daf58e85d5f9068e4f8da3538be
Summary:
Fixes some of the type errors in `ScrollView` that were previously being suppressed by comments. This also slightly simplifies the implementation of `ScrollView`.
Changelog:
[Internal]
Reviewed By: kacieb
Differential Revision: D25097225
fbshipit-source-id: a444db8179c91e264671d8f32431b93c4da8dfc4
Summary:
Rewrites `splitLayoutProps`, which is only used by `ScrollView`.
- Improve type safety by avoiding `DangerouslyImpreciseStyle`.
- Avoid allocating objects when it is not necessary.
- Avoid allocating a object enumeratig layout props by using a switch statement.
Changelog:
[Internal]
Reviewed By: JoshuaGross, kacieb
Differential Revision: D25097226
fbshipit-source-id: 2050c03b681024212c06a48b7eb05f28c14415f9
Summary:
Refactors `flattenStyle` so that it preserves the style type of the argument. This lets us avoid using `DangerouslyImpreciseStyleProp` where we can.
Changelog:
[Internal]
Reviewed By: JoshuaGross, nadiia, kacieb
Differential Revision: D25097227
fbshipit-source-id: df6af6fefab25dbb62e3c81897c3cef98619a9c7
Summary:
This is an extension of https://github.com/facebook/react-native/issues/29798 which was reverted due to cases where the soft keyboard could not be dismissed.
## 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] [Fixed] - Avoid eating clicks/taps into ScrollView when using physical keyboard
Pull Request resolved: https://github.com/facebook/react-native/pull/30374
Test Plan: Validated with iOS simulator that taps on default ScrollView will dismiss soft keyboard and be eaten if open, but taps are not eaten when emulating a connected physical keyboard.
Reviewed By: kacieb
Differential Revision: D24935077
Pulled By: lyahdav
fbshipit-source-id: 19d9cf64547e40a35f9363896e3abbdccb95b546
Summary:
Creates `NativeComponentRegistry` which makes native component initialization more declarative and configurable through an optionally configurable provider.
The next diff converts `ScrollView` to use this new abstraction as a demonstration. The plan would be to use this to replace all current manual call sites of `registerGeneratedViewConfig`, and then the ones generated via the Babel plugin.
Migrating to this will not change any production behavior, but it will enable verification of `ViewConfig` in development.
Changelog:
[Internal]
Reviewed By: JoshuaGross
Differential Revision: D25084468
fbshipit-source-id: 9c758ddc279bf937a401a868a066907a94098f37
Summary:
Updates `ReactScrollViewManager` and the `ViewConfig` for `ScrollView` so that they are equivalent.
- `inverted` was missing.
- `contentOffset` was missing differ on Android. (However, there does not seem to be any perceivable behavior difference besides the native `ViewConfig` being different.)
Changelog:
[Internal]
Reviewed By: JoshuaGross
Differential Revision: D25084470
fbshipit-source-id: 8bea3b7a692c1038819a4147b174583a4faa71e9
Summary:
Refactors the conversion of a `PartialViewConfig` into a `ViewConfig` to a separate function so that it can be reused.
Changelog:
[Internal]
Reviewed By: JoshuaGross
Differential Revision: D25084469
fbshipit-source-id: 8a7f53ff2c68860697c791c37a6abbfd3213a0f9
Summary:
Fixes types in `registerGeneratedViewConfig` and also removes some unnecessary hacks for the `ReactNativeViewViewConfig` type.
Changelog:
[Internal]
Reviewed By: JoshuaGross
Differential Revision: D25076608
fbshipit-source-id: 5cb2060e11db598b42fbb7f2f8aecfd7f4b262ef
Summary:
Cleans up the Flow types for React Native ViewConfig. After this diff, we will have two new canonical types:
- `ViewConfig` which is what we get from native and what is registered in the `ReactNativeViewConfigRegistry`.
- `PartialViewConfig` which is what we generate statically and augment at runtime before registering with the `ReactNativeViewConfigRegistry`.
Changelog:
[Internal]
Reviewed By: JoshuaGross
Differential Revision: D25075299
fbshipit-source-id: 4b53927b2db437b615447b711e83db355d0cfa55
Summary:
Hoists the call to `getNativeComponentAttributes` out of the verification function so that it's easier to keep track of when this function is and is not called.
The purpose of this will become clearer in a future refactor.
Changelog:
[Internal]
Reviewed By: ejanzer
Differential Revision: D25072600
fbshipit-source-id: bc42461baae3476fa7ecb6186c4256dd23921ed5
Summary:
Moves the `RN$Bridgeless` check as part of moving more logic out of the verification function.
Changelog:
[Internal]
Reviewed By: ejanzer
Differential Revision: D25072601
fbshipit-source-id: 929230c02a6eaa1b724f7fd2e1a691a7c20c4b11
Summary:
Changelog: [internal]
If value returned from `vImageBoxConvolve_ARGB8888` is negative, an error occurred.
Converting a negative number to `unsigned long` produces a large positive number (larger than memory). Trying to allocate that much memory fails, malloc returns NULL, and abort triggered inside `RCTBlurredImageWithRadius`.
To fix this we need to check for return value from `vImageBoxConvolve_ARGB8888`.
Documentation: https://developer.apple.com/documentation/accelerate/1515945-vimageboxconvolve_argb8888?language=objc
Reviewed By: JoshuaGross
Differential Revision: D25055827
fbshipit-source-id: 2c46ae6eea5cfcc95c2b552c7cd2bc60125fd24a
Summary:
Changelog:
[General] [Changed] - Added (DEV-only) `displayName` to some RN contexts to make them more easy to differentiate when debugging.
Reviewed By: lunaleaps
Differential Revision: D24993068
fbshipit-source-id: 4904259eda50444c2f74700a3540ff4fd02ac322
Summary:
Many third-party libraries (especially data management and caching ones) make use of long timeouts.
There are currently no plans to change `setTimeout` on Android to support firing when apps are in the background. In the meantime, this warning is not actionable for developers who are using these frameworks. Their workarounds are to 1) deal with the noise in their logs, or 2) suppress the warning.
Changelog:
[General][Removed] - Removed warning on Android for `setTimeout` with delays greater than 1 minute.
Reviewed By: lunaleaps
Differential Revision: D24964958
fbshipit-source-id: 1b40c8ba95d554c29dec74477aa63ea3ef8e4768
Summary:
Changelog: [internal]
`addListener` call needs a matching `removeListener` call. Otherwise a memory leak is introduced to the app.
This memory leak can retain a UIImage on iOS in Fabric and cause OOM.
Reviewed By: JoshuaGross
Differential Revision: D24860489
fbshipit-source-id: 2625e4bfec416d59e048d9b5ada3813019dd107c
Summary:
With nested FlatLists, three methods aren't firing: `onMomentumScrollBegin`, `onMomentumScrollEnd`, and `onScrollDragEnd`. This is because the nested child lists' methods are not being called.
This copies the solution for this from `onScrollBeginDrag` to the other three methods.
Changelog: [Fixed] Fix nested FlatList not firing onScrollDragEnd and onMomentum methods
Reviewed By: nadiia
Differential Revision: D24803418
fbshipit-source-id: 8685b1ab9f1bd5f67a88d93ac5de628d4bd69024
Summary:
Changelog: [Android] - Change StatusBar style handling strategy
Previously Android status bar can set to `dark-content` or `default`, I made the following changes:
- Added `light-content` to get align with iOS
- Changed the behavior of `default` from setting status bar with 'SYSTEM_UI_FLAG_LIGHT_STATUS_BAR' to not doing anything, I did this because 1, `setStyle('default')` is found called even without explicitly declared <StatusBar> on that surface, which I think should fail silently 2, my idea is that user should set status bar style to `dark-content` or `light-content` explicitly instead of using `default`.
- Fixed the bug found in Dating Settings's Second Look.
Reviewed By: RSNara
Differential Revision: D24714152
fbshipit-source-id: 76e7d0d45fd3b8c3733efaee81426f5f449cc7d8
Summary:
When shouldEnableLoggingForRequestUrl is false, ImageTelemetry is not initialized, and no logging is done.
* Replace `- (NSString *)loaderModuleNameForRequestUrl:(NSURL *)url` with `- (BOOL)shouldEnableLoggingForRequestUrl:(NSURL *)url`
* Rename RCTImageLoaderInstrumentableProtocol.h -> RCTImageLoaderLoggableProtocol.h
Reviewed By: fkgozali
Differential Revision: D24523984
fbshipit-source-id: a5463eceea1c40f9452b0ad2ee6bf047f71a02c1
Summary:
Adds an annotation in the performance logger that indicates if the component was rendered using Fabric or not.
Changelog: [internal]
Reviewed By: JoshuaGross, ShikaSD
Differential Revision: D24596131
fbshipit-source-id: 489f3a03f09c5425c870678ed593ee8f16a2d98b
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