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:
## 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
Summary:
## iOS
On iOS:
- All props come from ViewManagers
- All HostComponent ViewManagers extend <View/> ViewManager
https://pxl.cl/1SxdF
Therefore, it's safe to have all HostComponent Static View Configs extend <View/> Static View Config.
## Android
On Android, the 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, it's not safe to have all Android HostComponent Static View Configs to extend <View/>'s Static View Config:
1. No components actualy incorportate <View/>'s props
2. Some components don't even incorporate BaseViewManager's props.
## 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: yungsters
Differential Revision: D32187832
fbshipit-source-id: 9a057abb3f58801615891c21e42ad4cfa5c69f21
Summary:
This diff runs the codemod to add type annotations to function parameters in preparation for Flow's local type inference (LTI) project. I ran the codemod over xplat/js and reverted any files that had flow errors in them. See the list of commands run to see the regeneration of various files.
Changelog:
[Internal][Changed] - Added type annotations
Reviewed By: yungsters
Differential Revision: D32075270
fbshipit-source-id: 6a9cd85aab120b4d9e690bac142a415525dbf298
Summary:
When I upgraded React Native to Prettier v2.x, I removed `format` from a few files to reduce the number of changes.
This is a follow-up to bring back `format` and fix any remaining issues.
Changelog:
[Internal]
Reviewed By: zertosh
Differential Revision: D32287259
fbshipit-source-id: 37ea6d2c973b1db5d37c46d73675bdf436fb9a9d
Summary:
We are in the middle of a Prettier upgrade and some of the files which disagree between Prettier v1.x and v2.x are now being flagged by `eslint-plugin-prettier` as lint errors.
The correct fix here is probably to update `eslint-config-prettier` and `eslint-plugin-prettier`, but I am landing this first to unbreak CI.
Reviewed By: mendoncakeegan
Differential Revision: D32129458
fbshipit-source-id: a5206a5ef58f1d7614f9459c99b9e39109be6de9
Summary:
While investigating an issue hit on a recent sync of [react-native-windows](https://github.com/microsoft/react-native-windows) I noticed that e68cf7cee9 appears to have accidently inverted the logic to avoid checking native components.
`!UIManager.getViewManagerConfig(componentName)`
become
`UIManager.hasViewManagerConfig(componentName)`
losing the !
Also adding a check in PaperUIManager's getViewManagerConfig to avoid trying to call a sync method when using Chrome Debugging.
## Changelog
[Internal] [Fixed] - Restored the previous logic of deprecatedPropType
Pull Request resolved: https://github.com/facebook/react-native/pull/31164
Test Plan:
Change tested and being submitted in react-native-windows:
https://github.com/microsoft/react-native-windows/pull/7397
Reviewed By: hramos
Differential Revision: D30624302
Pulled By: fkgozali
fbshipit-source-id: 0f26e750283a1fa5eb5f44ecd2cf90617b6d931f
Summary:
Changelog: [Internal]
This diff add types to some of the common globals so uses of
them through `global` are now typed.
All the globals are marked as read-only for their intented uses.
However, some of them do have write cites (mostly are in tests to
deliberately set up a special test environment). Those write cites
are considered as "necessary evil" and annotated as `FlowFixMe`.
Reviewed By: yungsters
Differential Revision: D30158145
fbshipit-source-id: 93a99063361a4b7a1e33d9fc97a661be30a4d8f9
Summary:
This small PR updates the Flow types used in Dimensions. The following changes has been made:
* generic types has been replaced with types from `NativeDeviceInfo` (which already were used in event subscription update)
* ~simplification of `DisplayMetricsAndroid` by spreading via intersection with `DisplayMetrics` type and removing shared properties~
> I have tried both notations, but according to the lint, it looks like a Native Modules typing limitation which requires redundancy / code duplication in cases like this.
## 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] [Changed] - update Dimensions API Flow types
Pull Request resolved: https://github.com/facebook/react-native/pull/31898
Test Plan: Running `yarn flow` in the workspace yields no errors.
Reviewed By: yungsters
Differential Revision: D29932940
Pulled By: GijsWeterings
fbshipit-source-id: bf97bb972964c585207e2450ccf71d932555e291
Summary:
Changelog: [Internal]
If generators are provided natively, that should suggest that the JS source
code did not go through the regenerator-transform (e.g. in Metro Hermes profile),
then there is no need to set up the regenerator runtime.
This should save some work during the Core initialization.
Reviewed By: motiz88
Differential Revision: D29986751
fbshipit-source-id: 129f5122e8e4c05535ee2aa5da6970a66843e8cd
Summary:
Changelog: [Internal]
This diff only extracted the `isNativeFunction` used in `setUpTimers`
into the `FeatureDetection` utility, but later we will add more functions
in it and reuse them in other places.
Reviewed By: RSNara
Differential Revision: D29986750
fbshipit-source-id: 6e48e38d92ceccb35eead3c52e00e1eecb81b5b0
Summary:
preferred instead of preffered
## 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
-->
[CATEGORY] [TYPE] - Message
Pull Request resolved: https://github.com/facebook/react-native/pull/29858
Reviewed By: charlesbdudley
Differential Revision: D29998754
Pulled By: sota000
fbshipit-source-id: f13fef58e9154ddf8087944d53e022fb9afa6b1b
Summary:
## Context
In dev mode, Metro hijacks the JavaScript `console`, and prints all logs into the terminal running the Metro server.
## Problem
We have no way to distinguish between Bridge mode and Bridgeless mode logs. This makes it hard to tell catch warnings and errors are coming from bridgeless mode.
## Changes
- This diff adds a "NOBRIDGE" prefix to all React Native Metro logs coming from Bridgeless mode.
- Bridge mode console logs/warnings/errors are **unaffected**.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D29152292
fbshipit-source-id: 257b8140327cfd7a0a10aa229bcb88117231e452
Summary:
Creates `useRefEffect` which will be used by components in React Native.
Changelog:
[Internal]
Reviewed By: lunaleaps
Differential Revision: D28862440
fbshipit-source-id: 50e0099c1a3e0a0f506bf82e68984fc5a032f101
Summary:
Creates `useMergeRefs` which will be used by components in React Native.
Changelog:
[Internal]
Reviewed By: lunaleaps
Differential Revision: D28862439
fbshipit-source-id: 60eac7bcd6cceb06ee82181386b4712d642f5404
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:
Cleans up the `ExtendedError` internal type and moves it into a separate module instead of burying it in `parseErrorStack.js`.
Also, this resolves some unnecessary Flow type suppressions.
Changelog:
[Internal]
Reviewed By: GijsWeterings
Differential Revision: D28470299
fbshipit-source-id: 04093243f06f67f41567270ef9778f01c7549b05
Summary:
Having to import `useContext` every time is annoying, so this just creates a convenience function to get it.
Changelog: [Internal]
Reviewed By: GijsWeterings
Differential Revision: D28258305
fbshipit-source-id: 7293478f9baa11711a541f987225108871688e0e
Summary:
This diff deletes the registerGeneratedViewConfig API that is not used anymore.
This API was likely ONLY used internally at facebook, that's why I'm not deprecating it.
changelog: [Delete] Delete registerGeneratedViewConfig API
Reviewed By: fkgozali
Differential Revision: D28207558
fbshipit-source-id: 8598591e7ba1a7b001c87cb8728f2c599b1bbf63
Summary:
Some components are using `LogBoxData` directly, forcing logs to be shown on the screen even when LogBox is uninstalled. This changes all accesses to `LogBoxData` to go through `LogBox` so `uninstall` is used correctly.
It also changes when LogBox is installed, moving it from `AppContainer` to `InitializeCore` (which happens earlier) so we can capture more logs in LogBox.
Changelog: [General][Changed] Initialized LogBox earlier and centralized access in LogBox module
Reviewed By: rickhanlonii
Differential Revision: D27999361
fbshipit-source-id: 1115ef6b71e08cc33743d205da0064fbe9a74a0e
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:
Changes `Dimensions.addEventListener` to return an `EventSubscription` object that has a `remove()` method on it.
In an upcoming commit, calling `Dimensions.removeEventListener` will lead to a deprecation warning.
Changelog:
[General][Change] - `Dimensions.addEventListener` now returns an `EventSubscription`.
Reviewed By: kacieb
Differential Revision: D26808827
fbshipit-source-id: 0cfdc65b83c177f60937c1aa3a4cf633592f73d7
Summary:
Changes `Appearance.addChangeListener` to return an `EventSubscription` object that has a `remove()` method on it.
In an upcoming commit, calling `Appearance.removeChangeListener` will lead to a deprecation warning.
Changelog:
[General][Change] - `Appearance.addChangeListener` now returns an `EventSubscription`.
Reviewed By: kacieb
Differential Revision: D26696388
fbshipit-source-id: d0bdeffff3a2a366b3c11b6dc1417dfb2f1455c2
Summary:
This PR fixes few suppressed Flow issues in `VirtualizedList` component.
I have also removed few no longer valid Flow suppressions in `ActivityIndicator` and `ReactNativeTestTools`.
## Changelog
[General] [Fixed] - Flow: fix few issues in `VirtualizedList`,
[General] [Removed] - Flow: remove few no longer valid suppressions in `ReactNativeTestTools`
Pull Request resolved: https://github.com/facebook/react-native/pull/30128
Test Plan: Successful run of `yarn flow` check.
Reviewed By: kacieb
Differential Revision: D26489398
Pulled By: lunaleaps
fbshipit-source-id: db71d8bfeb3b6dc5a2738a73ac6644aef4a0311b
Summary:
Rewrites `NativeEventEmitter` to not extend `EventEmitter` and to compose `RCTDeviceEventEmitter` instead of (mis)using its exported `sharedSubscriber` property.
This makes it easier to reason about `NativeEventEmitter`. Also, the extraneous methods on `EventEmitter` are no longer inherited.
Changelog:
[General][Removed] - `NativeEventEmitter` no longer inherits from `EventEmitter`, so it no longer implements `removeListener` and `removeSubscription`. Instead, use the `remove()` method on the subscription object returned by `addListener`.
Reviewed By: rubennorte
Differential Revision: D26163562
fbshipit-source-id: c1aadb99bdefbaa36fece57ce74604e414f94d4d
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:
Simplifies the implementation of `DevSettings`. The fact that it uses `NativeEventEmitter` is an implementation detail and does not need to be exposed via inheritance.
This also enables more code to be removed from production builds (because the development implementation is now statically enclosed by `__DEV__`).
Changelog:
[General][Changed] - `DevSettings` no longer inherits from `NativeEventEmitter`
Reviewed By: RSNara
Differential Revision: D26140148
fbshipit-source-id: 99fa9d0c6ce8e365f89936aa12a4720f7a04b984
Summary:
This diff removes the call to UIManager.getViewManagerConfig into the deprecatedPropType method when static view configs are enabled
This was necessary to avoid innecessary calls to UIManager.getViewManagerConfig and to avoid loading UIManagerModule classes when static view configs are enabled
changelog: [internal] internal
Reviewed By: fkgozali, yungsters
Differential Revision: D26040855
fbshipit-source-id: 82cad9f4abe9898e781fd989ebaa03497dad926b
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:
This prevents having to modify too many files when we add the proper typing for that module
Changelog: [Internal]
Reviewed By: nadiia
Differential Revision: D25586848
fbshipit-source-id: 16001ada4a37a58f83b6e5a4400daebf9257be72
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:
Migrates `CodegenTypes` and its transitive dependencies to Flow strict to unblock this mode in Native Modules and Native Components.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D25540629
fbshipit-source-id: 7bed2ee58af7a789b50932734c7a86cf1719e2c5
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:
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
Paige Sun
Ramanpreet Nara
Andres Suarez
Gijs Weterings
Evan Yeung
Tim Yung
Andrew Coates
Xuan Huang
Steven Bell
Jimmy Zhang
Test User
Michael Chow
Daniel Sainati
Rubén Norte
David Vacca
Luna Wei
Micha Reiser
Mike Vitousek