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:
# 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:
## 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:
Without moving this, we would get this warning about a require cycle on the next diff, because DummyUIManager and LazyUIManager both need unstable_hasComponent.
```
(NOBRIDGE) WARN Require cycle: react-native-github/Libraries/NativeComponent/NativeComponentRegistry.js -> react-native-github/Libraries/ReactNative/UIManager.js -> react-native-github/Libraries/ReactNative/DummyUIManager.js -> react-native-github/Libraries/NativeComponent/NativeComponentRegistry.js
Require cycles are allowed, but can result in uninitialized values. Consider refactoring to remove the need for a cycle.
```
Changelog: [Internal]
Reviewed By: philIip, RSNara
Differential Revision: D33511566
fbshipit-source-id: fd8c9732408d08ab17335273f86168bf30747929
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:
## Changes
- StaticViewConfigValidator.validate() now outputs a ValidationOutput object, that contains a Array<Differences>, if invalid
- The Difference type now contains the nativeValue and the staticValue. This makes the validate() function more useful in reconciling ViewConfigs.
- Nothing should change in NativeComponentRegistry.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D32139973
fbshipit-source-id: a9556fa370d2c14f9e5d0540b44824cd61773958
Summary:
Creates a new `StaticViewConfigValidator` module that does strict, bidirectional validation. This is notably different from `verifyComponentAttributeEquivalence`, which is undirectional validation.
This will enforce that two configs are equivalent so we can start addressing the inconsistencies (especially per platform). It also improves upon the reporting format by providing more details about the invalidations.
It is hidden behind a `strict` runtime configuration parameter.
Changelog:
[Internal]
Reviewed By: RSNara
Differential Revision: D29024229
fbshipit-source-id: 10271945e089183f505205bd41de5e01faea7568
Summary:
This diff creates a new unstable method (unstable_hasComponent) to expose `global.__nativeComponentRegistry__hasComponent` into NativeComponentRegistry.js
changelog: [internal] internal
Reviewed By: yungsters
Differential Revision: D26716903
fbshipit-source-id: 52ff63b2779f41770b292cfc0b9022b1669d59fe
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:
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:
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:
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
Ramanpreet Nara
Andrei Shikov
Paige Sun
Andres Suarez
Gijs Weterings
Tim Yung
David Vacca
Micha Reiser