Summary:
## Problem
the partialLoadHandler is nil on line 338 of RCTImageLoader, therefore, if there is a cached image, it would crash on line 495.
## Change
Check if partialLoadHandler is nil on line 495 to prevent the crash
Changelog: [iOS][Changed] - fix the crash caused by nil partialLoadHandler
Reviewed By: appden
Differential Revision: D34544090
fbshipit-source-id: f9965700e529c5add1e25867a3772c053447d99a
Summary:
Annotate use of `ConcurrentRoot` in React in performance logger.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D34453147
fbshipit-source-id: 813a58ae964e5ae4ddf806a30597ee39d315e800
Summary:
This PR adds comments explaining the reason why the `NativeDatePickerAndroid.js` file was kept when removing `DatePickerAndroid`(7a770526c6 ) in order to prevent people from trying to delete it, as this file has no references in the Github repo
## Changelog
[Internal] [Added] - Add comments explaining the existence of NativeDatePickerAndroid
Pull Request resolved: https://github.com/facebook/react-native/pull/33159
Test Plan: Ensure builds are still working correctly, although this just adds a comment
Reviewed By: cortinico
Differential Revision: D34487638
Pulled By: lunaleaps
fbshipit-source-id: 42cb7331e98d69ff2f69f19bfbb2e65c063120f7
Summary:
## Problem
Previously the RN Image render the cached images asynchronously (line 555 and 594 prior to the change), which caused the images to render at least a frame later than the adjacent components.
## Change
In this change, we call partialLoadHandler with the cached image synchronously on the main thread.
Changelog: [iOS][Changed] - Synchronously render cached images
Reviewed By: p-sun
Differential Revision: D34487673
fbshipit-source-id: 0600c2fa5f7a1eca71b8582bbe968694cf211468
Summary:
Added a null check to native.value in Switch to fix regression from RN 66 -> stuck operation in mViewCommandOperations list in Android Release on initial layout of a screen with Switch component. If approved, please incorporate this fix into an RN 66 release.
## Changelog
[Android][Fixed] - Added a null check to native.value in Switch to fix https://github.com/facebook/react-native/issues/32594
Pull Request resolved: https://github.com/facebook/react-native/pull/32602
Test Plan: To reproduce, put a log in UIViewOperationQueue in dispatchViewUpdates you can see that the RetryableMountingException is no longer thrown for a screen with the Switch component on Android Release. As a result, mViewCommandOperations no longer has a stuck operation on initial layout.
Reviewed By: charlesbdudley
Differential Revision: D34397788
Pulled By: lunaleaps
fbshipit-source-id: 1cee3516fb987942dfa50ad1f2d11c965a947f05
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33140
Pull Request resolved: https://github.com/facebook/metro/pull/776
This Diff moves the `SegmentedComponentIOS` away from the core of React Native to move forward with the Lean Core effort
## Changelog
[General][Removed] - This diff removes the `SegmentedControlIOS` export from React Native. Internally, we are requiring `SegmentedControlIOS` directly now and externally people will have to use the community maintained module (https://github.com/react-native-segmented-control).
Reviewed By: cortinico
Differential Revision: D34304255
fbshipit-source-id: d4e2b0bda56708769603be6f164e6bf89997fd93
Summary:
This diff refactors LayoutAnimation to use ReactNativeFeatureFlags.ENABLE_LAYOUT_ANIMATION to enable / disable this feature
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D34349648
fbshipit-source-id: 90d1db6560867e44eeffbf03e5a84edadcdd55f9
Summary:
introduce ReactNativeFeatureFlags file to control FeatureFlags in React Native
changelog: [JS][Added] Create new API to configure FeatureFlags in ReactNative
Reviewed By: JoshuaGross
Differential Revision: D34349458
fbshipit-source-id: 73bb3704fc47e950ee1fcefcfaec1a85dfbcef59
Summary:
Deprecates the nonstandard `Promise.prototype.done` method. This also removes one call site within React Native itself that relied on this method.
As part of this we are also removing React Native's custom Flow definition for `Promise` in favour of the standard one built into Flow. This will flag uses of `done` as type errors for anyone using the default app template's `.flowconfig`.
In a future release of React Native, we will remove the `done` method from the built-in `Promise` polyfill.
Changelog:
[General][Deprecated] - Deprecate the Promise.prototype.done method and log a warning when it's called in development.
Reviewed By: yungsters
Differential Revision: D34222667
fbshipit-source-id: 4b9708ac20c45b3966fdb93e883ab7f8d80017c1
Summary:
Changelog: [Internal]
In the new architecture, when an interop component is being called, log instead of warn/error, since at the moment we expect this to happen often.
Reviewed By: fkgozali
Differential Revision: D34252666
fbshipit-source-id: 971156a1cd9ef9b788f677c49fa2c55bd86ad4fa
Summary:
Changelog: [Internal]
* Rename DummyUIManager to BridgelessUIManager
* Cleanup `RCTVirtualText` & `RCTShimmeringView` since the native changes from T107747313 are already in production, so these two will components always return a viewConfig in prod.
- `console.error` when deprecated Bridge UIManager method are being accessed.
- Make sure new BridgelessUIManager.js has the same method definition as [NativeUIManager.js](https://www.internalfb.com/code/fbsource/[e80c98b816183dcdfde1e81de01ba99aa6e30ed2]/xplat/js/react-native-github/Libraries/ReactNative/NativeUIManager.js?lines=15)
Reviewed By: RSNara
Differential Revision: D34203081
fbshipit-source-id: 99aafc2372b118d0c8cc41f7376e136dabae9bd5
Summary:
Before, when we called setValue with a PlatformColor, we unnecessarily called setValue on all component AnimatedValues before updateAnimatedNodeConfig.
This diff also fixes a bug where if we set a PlatformColor as the initial color, calling setValue with a non-PlatformColor would not have any effect. The fix is to reset AnimatedColor.nativeColor to null upon calling setValue.
Changelog:
[Internal] Optimize AnimatedColor when setting platform color
Reviewed By: javache
Differential Revision: D34187540
fbshipit-source-id: a0005d13f392a858d2eade912f2353f67eec1fd9
Summary:
Changes an internal call site that assumes image assets are `number`s to use the more general `ImageSource` type.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D34076216
fbshipit-source-id: dc0dc0c39982c87c21385828bb3357f9654d029f
Summary:
Adds `number` to the `ColorValue` union type.
Per our docs, React Native supports specifying colours as RGBA values packed into ints: https://reactnative.dev/docs/colors#color-ints. It looks like this case was missed in D6226807 (da047966e4) when we started typing the `StyleSheet` API with Flow.
Changelog: [General][Fixed] - Support numeric color values in StyleSheet's Flow types
Reviewed By: yungsters
Differential Revision: D34140748
fbshipit-source-id: 5bfe2995a473260926fa3c8b6926bb841615d393
Summary:
Now that animating color styles using native driver is supported on both Android and iOS, add color styles to the allowlist in NativeAnimatedHelper.
Changelog:
[General][Added] - Allow color styles to be animated using native driver
Reviewed By: mdvacca
Differential Revision: D34148038
fbshipit-source-id: c20dc149b805ec691a3936a77ab130fb4477a4c3
Summary:
Adds support for Animated.Color with native driver for iOS. Reads the native config for the rbga channel AnimatedNodes, and on update(), converts the values into a SharedColor.
Followup changes will include support for platform colors.
Ran update_pods: https://www.internalfb.com/intern/wiki/React_Native/Preparing_to_Ship/Open_Source_Pods/
Changelog:
[iOS][Added] - Support running animations with AnimatedColor with native driver
Reviewed By: sammy-SC
Differential Revision: D33860583
fbshipit-source-id: 990ad0f754a21e3939f2cb233bcfa793ef12eb14
Summary:
This comment was out of date.
Changelog: [Internal]
Reviewed By: sshic
Differential Revision: D34113966
fbshipit-source-id: 0768baa9238736aea26e354792096fea6bb7fcdb
Summary:
The views with touch event props are currently flattened by Fabric core, as we don't take event listeners into account when calculating whether the view should be flattened. This results in a confusing situation when components with touch event listeners (e.g. `<View onTouchStart={() => {}} /> `) or ones using `PanResponder` are either ignored (iOS) or cause a crash (Android).
This change passes touch event props to C++ layer and uses them to calculate whether the view node should be flattened or not. It also refactors events to be kept as a singular bitset with 32 bit (~`uint32_t`).
Changelog: [Changed][General] Avoid flattening nodes with event props
Reviewed By: sammy-SC
Differential Revision: D34005536
fbshipit-source-id: 96255b389a7bfff4aa208a96fd0c173d9edf1512
Summary:
Changelog: [Internal]
Fixes `normalizeColor` to always return the normalized color. Previously, when normalization was delegated to `normalizeColorObject`, we would return the *original* color object, which is a bug.
Reviewed By: javache
Differential Revision: D34048595
fbshipit-source-id: 083cbe36be2311ea9cffe8ef61e6a986840aec71
Summary:
# Problem
I removed the {eventName}: true entries from ViewConfigs validAttributes in D33303950 (ca5aaa7663). These entries were iOS-only. I removed them to achieve platform-consistency in native ViewConfigs.
This change broke the onLayout event for all React Native components. So, I reverted D33303950 (ca5aaa7663) for native ViewConfigs server-side. But I never got around to reverting D33303950 (ca5aaa7663) for static ViewConfigs.
# Changes
This diff reverts D33303950 (ca5aaa7663) for Static ViewConfigs, with server-side gating.
Now, these {eventName}: true ViewConfig validAttribute will be inserted into all view configs (static and native) **by default**.
Calling RCTDisableViewConfigEventValidAttributes(YES) on iOS will remove {eventName}: true ViewConfig ValidAttributes entries from Static ViewConfigs. (Previously, this method only removed the entries from native ViewConfigs).
https://www.internalfb.com/code/fbsource/[6615b0675bdf]/fbobjc/Apps/Wilde/FBReactModule2/FBReactModuleAPI/FBReactModuleAPI/Exported/FBReactModule.mm?lines=344
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D33933403
fbshipit-source-id: 17823ed99f97d7851f04e5cdab9c95667df13253
Summary:
This function is only used by the RNHostComponentList route. Let's move it into the route, so that we could keep the StaticViewConfigValidator slim.
This will also allow us to more heavily customize this function for the route.
Changelog: [Internal]
Reviewed By: p-sun
Differential Revision: D34026073
fbshipit-source-id: c3b3a93aed6007fadda2993afa52c28c028f6327
Summary:
In order to support AnimatedColor.setValue for platform colors, we need to pass the platform color object to the native animated node which will then resolve and apply the color.
Thus, the approach is:
- Add a new API updateAnimatedNodeConfig to NativeAnimatedModule
- [JS] On AnimatedColor.setValue, if the value is a platform color, then we call updateAnimatedNodeConfig
- [Android] We introduce AnimatedNodeWithUpdateableConfig interface with a method updateConfig. On ColorAnimatedNode.java, we use updateConfig to resolve and apply the color
Changelog:
[Internal][Fixed] - Use context from view when resolving platform color
Reviewed By: javache, mdvacca
Differential Revision: D34025193
fbshipit-source-id: 8b368f6b7cb2cf7cebe8b66461cd4185cbadd44c
Summary:
This event listener does nothing by default and will do nothing if (developer) users don't explicitly create some telemetry system for their own app.
This EventEmitter makes that easier but isn't necessarily tied to telemetry, especially since it does nothing at all by default.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D34060116
fbshipit-source-id: 9345a52f502e0225358fdaa1431c052a70fa54ce
Summary:
This will be used from the React JS renderer in a followup PR.
Changelog: [Added][JS] New event telemetry mechanism exposed from JS to supercede the Pressability-specific telemetry mechanism
Reviewed By: ryancat
Differential Revision: D33986916
fbshipit-source-id: 912d0b351869348f0ca6e5f6a882fc0501c2c7f0
Summary:
This PR fixes the opacity bug where it fails to properly react to state change. This PR resolves the issue detailed in https://github.com/facebook/react-native/issues/32476
## 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] - Fixed opacity value in TouchableOpacity
Pull Request resolved: https://github.com/facebook/react-native/pull/32956
Test Plan: The code I added in componentDidUpdate does solve the issue and passes all the test cases
Reviewed By: ryancat
Differential Revision: D33766718
Pulled By: cortinico
fbshipit-source-id: 951bedf22619fc12e66156d0a6074cd8adf1d3eb
Summary:
Invoke registerForRemoteNotifications on main UI thread to avoid error messages in Xcode.
Changelog:
[iOS][Fixed] - Invoke registerForRemoteNotifications on main UI thread.
Reviewed By: philIip
Differential Revision: D33780141
fbshipit-source-id: 64b825dfc15e7ac262e210b90bb334a7e415e402
Summary:
## Rationale
verifyComponentAttributeEquivalence is the legacy check for making sure that Static ViewConfigs match Native ViewConfigs. Eventually, we should just delete this module/check from the codebase.
## Changes
This diff migrates the RNHostComponentViewConfig differences screen to display the ViewConfig differences using the new StaticViewConfigValidator validation result vs the legacy validator's lefthandObjectDiff method.
## Benefits:
- Now, **all the diffing logic** on this route uses the new StaticViewConfigValidator.
- This takes us one step closer towards deleting verifyComponentAttributeEquivalence
- StaticViewConfigValidator [supports ignoring ViewConfig properties](https://fburl.com/code/2it5r7py). Now, the RNHostComponentViewConfig respects these ignores.
Changelog: [Internal]
Reviewed By: p-sun
Differential Revision: D34017602
fbshipit-source-id: 3ad909adcbb95b932a269dd55dd5445834a9cfd4
Summary:
Changelog: [Internal]
Fixes some files to use the preferred `import type {Foo}` syntax instead of `import {type Foo}`.
Reviewed By: rh389
Differential Revision: D34001108
fbshipit-source-id: 64675fefa71b6832118eabc60c825c65b87514d9
Summary:
Changelog:
[General][Fixed] - Remove illegal private property access in VirtualizedSectionList.scrollToLocation
`VirtualizedSectionList.scrollToLocation` internally uses `VirtualizedList`'s `_getFrameMetricsApprox` method. This method is private by convention (since it's `_`-prefixed), but under certain build setups this is also enforced at runtime, so using `scrollToLocation` can throw an error.
Here, we rename this internal method to `__getFrameMetricsApprox` (adding another leading underscore) which opts it out of being treated as private, while still communicating that it's not part of the public API. We also delete the Flow error suppression that masked this issue.
For reference: This convention for private methods (including the double-underscore opt out) has its roots in Facebook's pre-Babel [JSTransform](https://github.com/facebookarchive/jstransform/blob/master/visitors/es6-class-visitors.js) compiler and is implemented in Flow as [`munge_underscores=true`](https://flow.org/en/docs/config/options/#toc-munge-underscores-boolean).
Reviewed By: yungsters
Differential Revision: D33982339
fbshipit-source-id: 498563c59d42549c94fe90d363677d6d3ea35d2d
Summary:
Changelog:
[General] [Changed] Type the argument of Animated.interpolate as read-only
Reviewed By: javache
Differential Revision: D33950698
fbshipit-source-id: b959d34eb9752358f4a8ba1d290b56c099f535e0
Summary:
The JS-side animated node values were not being updated on AnimatedValue (and thus AnimatedValueXY); however, the native event "onAnimatedValueUpdate" is being handled properly in AnimatedNode. It turns out that single underscore prefixed methods are obfuscated at FB. And thus AnimatedValue._onAnimatedValueUpdateReceived was not getting called. Changing the method name to double underscore as a way to denote "protected" fixes the issue.
Changelog:
[General][Fixed] - JS animated node value updates properly when listener is attached
Reviewed By: yungsters
Differential Revision: D33962038
fbshipit-source-id: c4f60e1f1ccc0cef3e65b89034bdb91376a26416
Summary:
Removes the `propTypes` member from the `Image`, `Text`, and `TextInput` components.
They have been deprecated since React Native v0.66.
Changelog:
[General][Removed] - Removed `Image.propTypes`, `Text.propTypes`, and `TextInput.propTypes`.
Reviewed By: kacieb
Differential Revision: D33750298
fbshipit-source-id: 085f83ad838196bdd531b097b8ce5957270c3ad1
Summary:
Adds support for platform colors in AnimatedColor.
Passes the processed native color object to the native ColorAnimatedNode via the native config; ColorAnimatedNode then uses ColorPropConverter.getColor to resolve the resource path.
Note: setting a platform color via setValue on an existing AnimatedColor is not supported yet
Changelog:
[Android][Added] - Support platform color with AnimatedColor
Reviewed By: yungsters
Differential Revision: D33922266
fbshipit-source-id: 04d39a5ce0872b31d06ffbd4639d2f2213cf3314
Summary:
## Impact
Fix the Static ViewConfig for <View/>.
This diff fixes the base ViewConfig for all HostComponents on both platforms. Consequently, it simplifies SVC reconciliation efforts, by nearly eliminating the first of these classes of SVC errors:
1. Unexpected properties in SVC
2. Missing properties in SVC
3. Not matching properites in SVC
## What is the base ViewConfig on each iOS/Android?
**On iOS:**
- All props come from ViewManagers
- All HostComponent ViewManagers extend <View/> ViewManager
https://pxl.cl/1SxdF
Therefore, the base ViewConfig for all components should be <View/>'s static ViewConfig.
**On Android:**
The component model is a bit more complicated:
https://pxl.cl/1Vmp5
Takeaways:
- Props come from Shadow Nodes **and** ViewManagers
- Nearly all HostComponent ViewManagers extend BaseViewManager. But, that's not <View/>'s ViewManager.
- <View/>'s ViewManager is [ReactViewManager](https://fburl.com/code/0zalv8zk), which is a descendent of BaseViewManager, and declares its own ReactProps.
So, on Android, it's not safe for the base ViewConfig to be <View>'s ViewConfig:
1. No components actualy incorportate <View/>'s props
2. Some components don't even incorporate BaseViewManager's props.
So, what should the base ViewConfig be on Android?
- Nearly all components extend BaseViewManager. BaseViewManager must have a shadow node [that extends LayoutShadowNode](https://www.internalfb.com/code/fbsource/[47d68ebc06e64d97da9d069f1ab662b392f0df8a]/xplat/js/react-native-github/ReactAndroid/src/main/java/com/facebook/react/uimanager/BaseViewManager.java?lines=40). Therefore, we'll make the base ViewConfig on Android be generated by BaseViewManager + LayoutShadowNode.
## Changes
In this diff, I removed ReactNativeViewViewConfig, and introduced a new view config called PlatformBaseViewConfig. This ViewConfig partial will capture all the props available on all HostComponents on **both** platforms. This may not necessarily be the props made available on <View/>.
The only components that don't extend the base platform props are: RCTTextInlineImage. What we do with these components is TBD.
Changelog: [Internal]
Reviewed By: p-sun, yungsters
Differential Revision: D33135055
fbshipit-source-id: 7299f60ae45ed499ce47c0d0a6309a047bff90bb
Paige Sun
Mo Wang
Rubén Norte
Gabriel Donadel Dall'Agnol
jonathanmos
Dave McCabe
Riccardo Cipolleschi
David Vacca
Andrei Shikov
Amy Lee
Moti Zilberman
fabriziobertoglio1987
Genki Kondo
Ramanpreet Nara
Minsik Kim
Kacie Bawiec
Joshua Gross
Hetan Thakkar
Moses DeJong
Tim Yung