Summary:
In 2017, React published v15.5 which extracted the built-in `prop types` to a separate package to reflect the fact that not everybody uses them. In 2018, React Native started to remove `PropTypes` from React Native for the same reason. In 0.68 React Native introduced a deprecation warning which notified users that the change was coming, and in 0.69 we removed the PropTypes entirely.
The feedback we've received from the community is that there has not been enough time to migrate libraries off of PropTypes. This has resulted in users needing to patch the React Native package `index.js` file directly to add back the PropTypes, instead of migrating off of them. We can empathize with this fix short term (it unblocks the upgrade) but long term this patch will cause users to miss important changes to `index.js`, and add a maintenance cost for users.
Part of the reason there was not enough time is that we didn't do a good job surfacing libraries that were using PropTypes. This means, when you got a deprecation warning, it wasn't clear where the source of the usage was (either in your code or in a library). So even if you wanted to migrate, it was difficult to know where to actually make the change.
In the next release, we've made it easier to find call sites using deprecated types by [fixing the code frame in errors](https://github.com/react-native-community/cli/pull/1699) reporting in LogBox, and ensuring that [the app doesn't crash without a warning](https://github.com/facebook/react-native/pull/34650). This should make it easier to identify exactly where the deprecated usage is, so you can migrate it.
To help users get off of the patch, and allow more time to migrate, we're walking back the removal of PropTypes, and keeping it as a deprecation for a couple more versions. We ask that you either migrate off PropTypes to a type system like TypeScript, or migrate to the `deprecated-react-native-prop-types` package.
Once we feel more confident that the community has migrated and will not need to patch React Native in order to fix this issue, we'll remove the PropTypes again. **If you have any trouble finding the source of the PropType usage, please file an issue so we can help track it down with you.**
Changelog:
[General][Changed] - Add back deprecated PropTypes
Reviewed By: yungsters
Differential Revision: D40725705
fbshipit-source-id: 8ce61be30343827efd6dc89a012eeef0b6676deb
Summary:
Changelog:
[General][Added] - Introduce `useAnimatedValue` hook to make it easier working with `Animated.Value`s in function components.
Reviewed By: javache
Differential Revision: D40434219
fbshipit-source-id: 3caf6ad98d11a534b8cc6816820bc1d125150380
Summary:
`VirtualizedList_EXPERIMENTAL` is a fork of VirtualizedList. It was originally created for the purpose of keyboard/a11y fixes, which required the list to allow rendering discontiguous regions of cells. So, the large part of the refactor is in the data structure used to represent state (now a sparse bitmask), and building out the render function to operate off the bitmask.
This structure allows pre-rendering areas where we know focus must be able to be synchronously be moved to. This is exercised on platforms like Windows and macOS which fire view level focus events. The new implementation otherwise aims to preserve near-exact list behavior as previously.
Apart from the structure change, the refactor has made the code (subjectively) a lot easier to reason about, and there are now stronger internal invariants than before. The bitmask structure also enables new approaches for nested list stability, and implementing OffScreen.
**Why ship it now?**
Having two implementations has multiple times prevented other changes to VirtualizedList, so it is incurring a constant engineer cost.
At this point, we have a lot of reason to be confident in the maturity of the new list implementation (see the test plan below). So, reconciling the implementations not only unlocks the enhancements of the new list, but unblocks future changes to VirtualizedList.
## Test Plan
1. **Unit tests:** A few dozen unit tests were added to VirtualizedList, validating the regions it renders in response to injected input, across its API surface. Both VirtualizedList implementations must pass the same tests, around expected behavior.
2. **RNTester:** Scenarios in RNTester were manually validated, and all worked as before
3. **New invariants:** I added a lot of internal logic checks and bounds checks as invariant violations, to try to produce signal if any part of the refactor went unexpected in the wild.
4. **MSFT Rollout:** I rolled out the changes as a fork of VirtualizedList at MSFT to a couple of high-usage surfaces using Android, iOS, and Windows on Paper. Some invariant violations were surfaced and fixed, but telemetry showed solid system and scenario health with the change.
5. **Meta import:** Fixed all land-blocking test failures when using the new list. These were confined to updating snapshots, and adding additional checks for invalid input.
6. **Panel apps:** Manually validated top-level surfaces of panel apps in debug/release modes. Fixed a couple of invariant violations and novel usages. Profiled new JS structures against an expensive list with Hermes profiler.
7. **Facebook App Rollout:** After some manual validation of top-level surfaces, the change was rolled out to Facebook for Android and iOS as an experiment. New invariant violations were fixed, and the change has sat in production for several weeks at this point, while measuring impact to metrics like error rate, responsiveness, and impressions.
This is the first introduction to all of OSS, and some Meta internal apps. This means there may still be novel usages of VirtualizedList that were not picked up during testing, but I think there has been enough diligence to roll out what has been tested, and forward fix anything unexpected that might still come up.
Changelog:
[General][Changed] - Ship VirtualizedList_EXPERIMENTAL
Reviewed By: javache
Differential Revision: D40259791
fbshipit-source-id: 63eee9381d197a1e38ae663b2158436ff135c0e1
Summary:
This refactors the systrace module to:
1) Migrate it to ESM
2) Fix the typing of certain parameters (e.g.: `eventName` and `cookie` shouldn't be optional)
2) Fix TypeScript definitions
3) Add inline documentation for methods
4) Add args (metadata) to all methods where it's supported in fbsystrace (`endEvent` and `endAsyncEvent`).
5) Make `setEnabled` a no-op. The only place where this method is called is from native, when starting a profile session. The problem is that implementation for Systrace in OSS (https://github.com/facebook/react-native/blob/main/ReactAndroid/src/main/java/com/facebook/systrace/Systrace.java#L40-L42) doesn't support listeners, so this wouldn't work correctly there. It also doesn't get called with Venice, so instead of fixing it for Venice with the same Meta-internal behavior, I decided to fix it for everyone with the synchronous method.
I'm not considering this a change in the public API of systrace because this module has been broken in OSS for ages and I'm assuming no one's using it at this point.
Changelog: [internal]
Reviewed By: rshest
Differential Revision: D40095842
fbshipit-source-id: fee41b2b7ae23aefe059e390c55d139db75247c5
Summary:
This PR refactors the Animated directory to use ESModule imports/exports instead of using a mixture of the 2 module formats, as requested on https://github.com/facebook/react-native/issues/34425.
## Changelog
[Internal] [Changed] - Convert all files in the Animated directory to use ESModule imports/exports
Pull Request resolved: https://github.com/facebook/react-native/pull/34539
Test Plan: This doesn't really add or modify any existing features so checking if CI passes should be enough
Reviewed By: yungsters
Differential Revision: D39235720
Pulled By: yungsters
fbshipit-source-id: 84b4c0a71dc9fca1ab7053263f1cf7c336df58c1
Summary:
This diff creates a proxy module to interact with the React Native renderer. The goal of this proxy is to decouple usages of several functions (e.g.: `findNodeHandle`, etc.) from the actual renderer used in an app. This way, we can easily switch between renderers without having to change code depending on it.
This will be useful to remove a specific renderer from an app bundle when it's no longer used (e.g.: Paper on the Facebook App).
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D39205975
fbshipit-source-id: 05289c0c3c8cd26d81aa1d2163097c73ec40c6ad
Summary:
Improves upon the existing prop types error messages to first recommend migrating to a type system (before recommending the usage of `deprecated-react-native-prop-types`).
## Changelog
[General][Changed] - Minor change to PropTypes error message.
Pull Request resolved: https://github.com/facebook/react-native/pull/34392
Test Plan: Careful code inspection.
Reviewed By: rickhanlonii
Differential Revision: D38632723
Pulled By: yungsters
fbshipit-source-id: 88e44116475c7d93bc561c9ab6883855d6d79a7e
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:
Removes `ColorPropType`, `EdgeInsetsPropType`, `PointPropType`, and `ViewPropTypes` from the React Native Public API.
Accessing these will now cause an error to be thrown with a message to use the `deprecated-react-native-prop-types` package.
These were deprecated in React Native v0.66.
Changelog:
[General][Removed] - Removed `ColorPropType`, `EdgeInsetsPropType`, `PointPropType`, and `ViewPropTypes`.
Reviewed By: kacieb
Differential Revision: D33746966
fbshipit-source-id: 61d264d133f42008c7ff252e6ebbb8b47747939c
Summary:
Deprecates `prop-types` from React Native.
Existing use cases will be presented with a warning to migrate to the newly published `deprecated-react-native-prop-types` module.
In a subsequent release, these will be removed from React Native.
Changelog:
[General][Changed] - Accessing `Image.propTypes`, `Text.propTypes`, `TextInput.propTypes`, `ColorPropType`, `EdgeInsetsPropType`, `PointPropType`, or `ViewPropTypes` now emits a deprecation warning.
Reviewed By: kacieb
Differential Revision: D29019309
fbshipit-source-id: 21e518e588fa05c498cc75ba81f69cfa8a9d0613
Summary:
This component has been merged with `StatusBar` and deprecated since [Jun 24, 2019](a833778553)
## 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
-->
[JavaScript] [Removed] - refactor!: drop deprecated `StatusBarIOS`
Pull Request resolved: https://github.com/facebook/react-native/pull/31466
Test Plan: Warning when user imports `StatusBarIOS`
Reviewed By: yungsters
Differential Revision: D30109324
Pulled By: lunaleaps
fbshipit-source-id: fa2d3aa2cf35206ed8a196e09f12af57d3b61ccc
Summary:
Unifies the platform-specific implementations of `AccessibilityInfo` to simplifying checking Flow types and making changes to the module.
Changelog:
[Internal]
Reviewed By: mdvacca
Differential Revision: D27578847
fbshipit-source-id: 84dc274a66acd22fc6f1dd2773a4e4630761e17d
Summary:
Updated some warning messages that shows up when importing deprecated modules to have the updated name space.
## 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] [Changed] - Update package name warning of deprecated modules
Pull Request resolved: https://github.com/facebook/react-native/pull/30911
Test Plan: Updated link works as expected
Reviewed By: TheSavior
Differential Revision: D26318425
Pulled By: PeteTheHeat
fbshipit-source-id: 74a9909698236e62af8da23644df65c75bb1df11
Summary:
Part of https://github.com/react-native-community/releases/issues/207
Migrate warnings in index.js to point to new lean core repos
NOTE: some npm modules has been transferred to new nom namespace, such as `react-native-picker/picker` `react-native-async-storage/async-storage` `react-native-masked-view/masked-view`.
Some lean core repo has been transferred to new repo, but its npm namespace remains the same. ex: clipboard module exists in react-native-clipboard/clipboard repo, but npm package name is still `react-native-community/clipboard` (they're planned to be migrated in the future)
## 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] [Changed] - Migrate warnings in index.js to point to new lean core repos
Pull Request resolved: https://github.com/facebook/react-native/pull/30422
Test Plan:
- Updated repo URL can be accessed
- Updated npm package can be installed
Reviewed By: rickhanlonii
Differential Revision: D25077750
Pulled By: cpojer
fbshipit-source-id: b736ea449835bdf3d2a2f85e5c86e5253b90db78
Summary:
As of right now, index.js contains a big blob of imports that are mostly in alphabetical order, with a few exceptions. In addition, the imports aren't separated by Components / API / Plugins, so comments were added for ease of future maintainability.
## Changelog
[Internal] [Changed] - Reordered imports into alphabetical order and added comments to divide imports into sections (components, apis, plugins, prop types)
Pull Request resolved: https://github.com/facebook/react-native/pull/30217
Test Plan:
This change did not change the codebase. Building rn-tester still works.
rickhanlonii
Reviewed By: cpojer
Differential Revision: D24490715
Pulled By: rickhanlonii
fbshipit-source-id: 7340395c8e10833b700dcfe8e83ab4a66b79e47b
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:
Removes the legacy `react-animated` package configuration and collapses the `Animated/src/` directory into `Animated/`.
Also, reconfigures all references to `Animated/src/` to just be `Animated/`.
Changelog:
[Internal]
Reviewed By: cpojer
Differential Revision: D22450848
fbshipit-source-id: 9fd4861e9f357d817d82e9fec71967a2936a3830
Summary:
Creates a `RootTag` type and refactors the `RootTagContext` module a bit.
This creates space for eventually changing `RootTag` into an opaque type that is only created once by `AppContainer`, and only consumed by native abstractions.
Changelog:
[Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: cpojer
Differential Revision: D21127173
fbshipit-source-id: 60177a6e5e02d6308e87f76d12a271114f8f8fe0
Summary:
This change removes the `ColorAndroid` API. It was added more as a validation tool than as something useful to a developer. When making the original [PlatformColor PR](https://github.com/facebook/react-native/pull/27908) we felt it was valuable and useful to have working platform specific methods for the two platforms in core to test that the pattern worked in app code (PlatformColorExample.js in RNTester) and that the Flow validation worked, etc. Practically `PlatformColor()` is more useful to a developer on Android than `ColorAndroid()`. Now that the construct has served its purpose, this PR removes the `ColorAndroid` function and its related tests and other collateral.
## 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
-->
[Android] [Removed] - Remove ColorAndroid function as it adds no value over PlatfromColor
Pull Request resolved: https://github.com/facebook/react-native/pull/28577
Test Plan: RNTester in both iOS and Android was tested. Jest tests, Flow checks, Lint checks all pass.
Reviewed By: cpojer
Differential Revision: D20952613
Pulled By: TheSavior
fbshipit-source-id: 7d2cbaa2a347fffe59a1f3a26a210676008fdac0
Summary:
Move CheckBox JS files to FB internal
## Changelog:
[General] [Removed] This diff removes the CheckBox export from React Native. Internally, we are requiring CheckBox directly now and externally people will have to use the community maintained module.
Reviewed By: cpojer
Differential Revision: D20910775
fbshipit-source-id: 809e135dc3f68911ac0a004e6eafa8488f0d5327
Summary:
Some of the repository name of Lean Core(https://github.com/facebook/react-native/issues/23313) libraries has been renamed.
This PR updates the warning message to display the updated url.
## Changelog
[General] [Changed] - Update warning message of deprecated imports
Pull Request resolved: https://github.com/facebook/react-native/pull/28452
Test Plan: updated URL can be accessed.
Reviewed By: cpojer
Differential Revision: D20745184
Pulled By: TheSavior
fbshipit-source-id: 2c3ed6a000b45022ca6c4862305aa567c4d18b2e
Summary:
This Pull Request implements the PlatformColor proposal discussed at https://github.com/react-native-community/discussions-and-proposals/issues/126. The changes include implementations for iOS and Android as well as a PlatformColorExample page in RNTester.
Every native platform has the concept of system defined colors. Instead of specifying a concrete color value the app developer can choose a system color that varies in appearance depending on a system theme settings such Light or Dark mode, accessibility settings such as a High Contrast mode, and even its context within the app such as the traits of a containing view or window.
The proposal is to add true platform color support to react-native by extending the Flow type `ColorValue` with platform specific color type information for each platform and to provide a convenience function, `PlatformColor()`, for instantiating platform specific ColorValue objects.
`PlatformColor(name [, name ...])` where `name` is a system color name on a given platform. If `name` does not resolve to a color for any reason, the next `name` in the argument list will be resolved and so on. If none of the names resolve, a RedBox error occurs. This allows a latest platform color to be used, but if running on an older platform it will fallback to a previous version.
The function returns a `ColorValue`.
On iOS the values of `name` is one of the iOS [UI Element](https://developer.apple.com/documentation/uikit/uicolor/ui_element_colors) or [Standard Color](https://developer.apple.com/documentation/uikit/uicolor/standard_colors) names such as `labelColor` or `systemFillColor`.
On Android the `name` values are the same [app resource](https://developer.android.com/guide/topics/resources/providing-resources) path strings that can be expressed in XML:
XML Resource:
`@ [<package_name>:]<resource_type>/<resource_name>`
Style reference from current theme:
`?[<package_name>:][<resource_type>/]<resource_name>`
For example:
- `?android:colorError`
- `?android:attr/colorError`
- `?attr/colorPrimary`
- `?colorPrimaryDark`
- `android:color/holo_purple`
- `color/catalyst_redbox_background`
On iOS another type of system dynamic color can be created using the `IOSDynamicColor({dark: <color>, light:<color>})` method. The arguments are a tuple containing custom colors for light and dark themes. Such dynamic colors are useful for branding colors or other app specific colors that still respond automatically to system setting changes.
Example: `<View style={{ backgroundColor: IOSDynamicColor({light: 'black', dark: 'white'}) }}/>`
Other platforms could create platform specific functions similar to `IOSDynamicColor` per the needs of those platforms. For example, macOS has a similar dynamic color type that could be implemented via a `MacDynamicColor`. On Windows custom brushes that tint or otherwise modify a system brush could be created using a platform specific method.
## Changelog
[General] [Added] - Added PlatformColor implementations for iOS and Android
Pull Request resolved: https://github.com/facebook/react-native/pull/27908
Test Plan:
The changes have been tested using the RNTester test app for iOS and Android. On iOS a set of XCTestCase's were added to the Unit Tests.
<img width="924" alt="PlatformColor-ios-android" src="https://user-images.githubusercontent.com/30053638/73472497-ff183a80-433f-11ea-90d8-2b04338bbe79.png">
In addition `PlatformColor` support has been added to other out-of-tree platforms such as macOS and Windows has been implemented using these changes:
react-native for macOS branch: https://github.com/microsoft/react-native/compare/master...tom-un:tomun/platformcolors
react-native for Windows branch: https://github.com/microsoft/react-native-windows/compare/master...tom-un:tomun/platformcolors
iOS
|Light|Dark|
|{F229354502}|{F229354515}|
Android
|Light|Dark|
|{F230114392}|{F230114490}|
{F230122700}
Reviewed By: hramos
Differential Revision: D19837753
Pulled By: TheSavior
fbshipit-source-id: 82ca70d40802f3b24591bfd4b94b61f3c38ba829
Summary:
*Pressable* is a component which is intended to replace the Touchable* components such as *TouchableWithoutFeedback* and *TouchableOpacity*. The motivation is to make it easier to create custom visual touch feedback so that React Native apps are not easily identified by the “signature opacity fade” touch feedback.
We see this component as eventually deprecating all of the existing Touchable components.
Changelog:
[Added][General] New <Pressable> Component to make it easier to create touchable elements
Reviewed By: yungsters
Differential Revision: D19674480
fbshipit-source-id: 765d657f023caea459f02da25376e4d5a2efff8b
Summary:
This diff replaces YellowBox with YellowBoxDeprecated, adding warnings for using the module directly instead of YellowBox. Also adds a no-op message for unstable_enableLogBox.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D19949700
fbshipit-source-id: 269c341a2cedcdb2f7a80947d3239db078238201
Summary:
We need to export this so that users can call methods like:
```
LogBox.ignoreAllLogs();
LogBox.ignoreLogs([/whatever/]);
```
Changelog: [General] [Added] Export LogBox module
Reviewed By: TheSavior
Differential Revision: D19813773
fbshipit-source-id: 8c301c16247c5b9f4b23e8afaf6a9783b4b4c724
Summary:
Add warning messages for Clipboard, SegmentedControlIOS, ProgressViewIOS, ProgressBarAndroid that has been published in community repo.
## Changelog
[General] [Deprecated] - Add deprecation warnings for Clipboard, SegmentedControlIOS, ProgressViewIOS, ProgressBarAndroid.
Pull Request resolved: https://github.com/facebook/react-native/pull/27929
Test Plan: yarn lint
Differential Revision: D19690577
Pulled By: cpojer
fbshipit-source-id: d53fbe9980c5eb2f7b62deb397064aa727d513bd
Summary:
Add warning message for development that is trying to use ToolbarAndroid that has been removed from ReactNative in 0.61
Ref: https://github.com/facebook/react-native/issues/26591
## Changelog
[General] [Deprecated] - Add warning message for trying to use ToolbarAndroid which has been removed from the core.
Pull Request resolved: https://github.com/facebook/react-native/pull/27930
Differential Revision: D19690581
Pulled By: cpojer
fbshipit-source-id: 8e404fe62651fba4940199c74c45270d6e853740
Summary:
This diff adds a new `unstable_enableLogBox` function to opt-into the new LogBox experience. If LogBox is not enabled early enough, we show an error with instructions.
With this, LogBox can be enabled with:
```
require('react-native').unstable_enableLogBox();
```
Changelog: [General] [Adds] unstable_enableLogBox
Reviewed By: zackargyle, rubennorte
Differential Revision: D18808940
fbshipit-source-id: 4b0234ddc4d1646515bf63110d5b02133780512e
Summary:
Changelog: [Internal]
Reverting the import to the previous local module style since importing from react-native seems to introduce some perf regression. We'll revisit this later in the future.
Reviewed By: yungsters
Differential Revision: D18383893
fbshipit-source-id: f11d46a4545768f39199fd6fd22fcf14905d0a74
Summary:
Changelog: [Internal]
* The original intention was to export both `get()` and `getEnforcing()` from TurboModuleRegistry.js, so define export default there
* Exposes `TurboModule` type on the top-level `'react-native'` import
* Tried this out on `NativeSegmentFetcher`
Reviewed By: yungsters
Differential Revision: D18262535
fbshipit-source-id: a46f2b8b6147531998efac8aa3b8259885224902
Summary:
In React Native there are three types of "Native" components.
```
createReactClass with NativeMethodsMixin
```
```
class MyComponent extends ReactNative.NativeComponent
```
```
requireNativeComponent('RCTView')
```
The implementation for how to handle all three of these exists in the React Native Renderer. Refs attached to components created via these methods provide a set of functions such as
```
.measure
.measureInWindow
.measureLayout
.setNativeProps
```
These methods have been used for our core components in the repo to provide a consistent API. Many of the APIs in React Native require a `reactTag` to a host component. This is acquired by calling `findNodeHandle` with any component. `findNodeHandle` works with the first two approaches.
For a lot of our new Fabric APIs, we will require passing a ref to a HostComponent directly instead of relying on `findNodeHandle` to tunnel through the component tree as that behavior isn't safe with React concurrent mode.
The goal of this change is to enable us to differentiate between components created with `requireNativeComponent` and the other types. This will be needed to be able to safely type the new APIs.
For existing components that should support being a host component but need to use some JS behavior in a wrapper, they should use `forwardRef`. The majority of React Native's core components were migrated to use `forwardRef` last year. Components that can't use forwardRef will need to have a method like `getNativeRef()` to get access to the underlying host component ref.
Reviewed By: rickhanlonii
Differential Revision: D17563615
fbshipit-source-id: b9e6042805517d502770fcba37301c2c5b6452b6
Ruslan Lesiutin
Rick Hanlon
Fabrizio Cucci
Nick Gerleman
Rubén Norte
Gabriel Donadel Dall'Agnol
Rubén Norte
Tim Yung
Michael Sokolnicki
Riccardo Cipolleschi
maaxg
Andres Suarez
Andres Riveros Moya
Luis Miguel Alvarado
Luna Wei
Kacie Bawiec
Nadiia D
Jorge Rossi
Jimmy Zhang
Jesse Katsumata
Liang Liu
simek
Jordan Brown
Tom Underhill
Lauren Tan
Eli White
Rick Hanlon
Kevin Gozali
