Summary:
This PR implements `inset` logical properties as requested on https://github.com/facebook/react-native/issues/34425. This implementation includes the addition of the following style properties
- `inset`, equivalent to `top`, `bottom`, `right` and `left`.
- `insetBlock`, equivalent to `top` and `bottom`.
- `insetBlockEnd`, equivalent to `bottom`.
- `insetBlockStart`, equivalent to `top`.
- `insetInline`, equivalent to `right` and `left`.
- `insetInlineEnd`, equivalent to `right` or `left`.
- `insetInlineStart`, equivalent to `right` or `left`.
## Changelog
[GENERAL] [ADDED] - Add Fabric implementation of inset logical properties
Pull Request resolved: https://github.com/facebook/react-native/pull/35692
Test Plan:
1. Open the RNTester app and navigate to the `View` page
2. Test the new style properties through the `Insets` section
<table>
<tr>
<td>Android</td>
<td>iOS</td>
</tr>
<tr>
<td><img src="https://user-images.githubusercontent.com/11707729/208821212-fbbac6ed-09a4-43f4-ba98-dfd2cbabf044.png" alt="1" width="360px" />
</td>
<td>
<img src="https://user-images.githubusercontent.com/11707729/208816997-ef044140-8824-4b1b-a77b-085f18ea9e0e.png" alt="2" width="360px" />
</td>
</tr>
</table>
Reviewed By: NickGerleman
Differential Revision: D42193661
Pulled By: ryancat
fbshipit-source-id: 3db8bcd2c4db0ef4886b9ec49a46424d57362620
Summary:
Changelog: [Internal]
Codemod-bot already hardcoded this to false a while back, so cleaning up the code related to it.
Reviewed By: RSNara
Differential Revision: D41615378
fbshipit-source-id: 7b62b20b8e25f0a06d207b2457d6caf9ad5c695e
Summary:
Changelog: [Internal]
`NativeComponentRegistryUnstable.js` has Flow syntax but no `flow` directive. It seems to typecheck fine so I'm adding the directive here. (Plus `format` for good measure.)
Reviewed By: huntie
Differential Revision: D41547266
fbshipit-source-id: 1b6a03c705add91843633166a245d0447a21af6d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35342
This is a native implementation of the JS shimmed layout-specific properties in https://github.com/facebook/react-native/pull/35316.
There is an experiment splitting the prop splitting codepath in Fabric, so this change effectively has two implementations depending on whether `enablePropIteratorSetter` is enabled.
None of these changes make sense to propagate Yoga. `inlineEnd`, etc are already mapped to `YGEdgeStart` and `YGEdgeEnd`, but RN's mapping used a different name. Then `blockStart`, `blockEnd`, map directly to existing edges in all cases since we don't support a writing mode.
On web, the last value in the style which computes the given dimension is given precedence. E.g. if "left" comes after "start" it will be chosen. Yoga stylesheets are unordered, and precedence for edges is given based on specificity (left > start > horizontal > all).
We give precedence to new renamings (e.g. start to inlineStart), but to preserve consistent behavior, we give precedence to specific edges before overwriting them with flow relative ones (e.g. marginTop has precedence over marginBlockStar).
Changelog:
[General][Added] - Add Fabric implementation of flow-relative padding and margin
Reviewed By: javache
Differential Revision: D41267765
fbshipit-source-id: 896e2ed71fe8bf83aef00b0a9d70fd20b2ce47a7
Summary:
This PR adds React native binding for https://github.com/facebook/yoga/pull/1116
## Changelog
[General] [Added] - Flex gap yoga bindings
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/34974
Test Plan:
Run rn tester app and go to view example. You'll find a flex gap example. Example location - `packages/rn-tester/js/examples/View/ViewExample.js`
### Tested on
- [x] iOS Fabric
- [x] iOS non-fabric
- [x] Android Fabric
- [x] Android non-fabric
To test on non-fabric Android, I just switched these booleans. Let me know if there's anything else I might have missed.
<img width="674" alt="Screenshot 2022-10-14 at 3 30 48 AM" src="https://user-images.githubusercontent.com/23293248/195718971-7aee4e7e-dbf0-4452-9d47-7925919c61dc.png">
Reviewed By: mdvacca
Differential Revision: D40527474
Pulled By: NickGerleman
fbshipit-source-id: 81c2c97c76f58fad3bb40fb378aaf8b6ebd30d63
Summary:
needsOffscreenAlphaCompositing is supported on both iOS and Android, but was missing from the view config for Android.
https://reactnative.dev/docs/view#needsoffscreenalphacompositinghttps://fburl.com/code/hfxkrur1
Changelog:
[Internal][Fixed] - Add needsOffscreenAlphaCompositing to view config
Reviewed By: NickGerleman
Differential Revision: D38580371
fbshipit-source-id: 9b577079e575d73c94d7c0d0298ba880c1438099
Summary: Changelog: [Internal] - We can now remove the '2' suffix as we had an internal implementation that was not truly aligned with W3C pointers but used the same name. We have aligned the internal types to match w3c so we can now remove the suffix that differentiates them.
Reviewed By: vincentriemer
Differential Revision: D37545813
fbshipit-source-id: 6f2336ae9e314066c340161113268c1f28621a71
Summary: Add annotations to function parameters required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predictable.
Reviewed By: bradzacher
Differential Revision: D37388949
fbshipit-source-id: cdcbc98035ce9b6994842005ea46df42de54f9b8
Summary: Add annotations to function parameters required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predicatable.
Reviewed By: evanyeung
Differential Revision: D37353648
fbshipit-source-id: e5a0c685ced85a8ff353d578b373f836b376bb28
Summary:
Changelog: [Internal][SVC][JS] Refactor the JS base SVC StaticViewConfig to be easier to understand
This diff is a refactor that doesn't change any logic.
# Context
NativeViewConfigs are generated from RCTViewManager in iOS and ViewManager in Android.
StaticViewConfigs are partially generated from JS, and partially handwritten in JS.
We've noticed in at least 2 instances that engineers who add new props to NativeViewConfigs sometimes don't put props in the correct place for StaticViewConfigs, and thus they accidentally break the landblocking jest e2e test that validates the StaticViewConfigs matches the NativeViewConfigs.
The human error is mostly because PlatformBaseViewConfig.js was too nested to be easily understood. This diff refactors PlatformBaseViewConfig.js and adds clarifying comments.
Reviewed By: RSNara
Differential Revision: D35623775
fbshipit-source-id: 498a3daa812fa314821a2e7cb7d6f809900dbe3a
Summary:
Changelog: [Internal][Fixed] Fix StaticViewConfigs for Android, by removing iOS-only accessibilityLanguage prop
The accessibilityLanguage was a prop added to RCTViewManager, that is iOS-only, so it shouldn't exist in the SVCs for Android.
Reviewed By: RSNara
Differential Revision: D35630945
fbshipit-source-id: 7ed7f2619f73bb88babfbb207793d5415addaee6
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:
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
Gabriel Donadel Dall'Agnol
Sam Zhou
Pieter De Baets
Moti Zilberman
Nick Gerleman
Nishan
Tim Yung
Rujin Cao
Luna Wei
Genki Kondo
Eric Edouard
Pieter Vanderwerff
Vincent Riemer
Paige Sun
Diego Pasquali
Ramanpreet Nara
Andrei Shikov
Andres Suarez
Gijs Weterings
Tim Yung
David Vacca
Micha Reiser
