Commit Graph

9 Commits

Author SHA1 Message Date
Vincent Riemer c5cb707ba8 Add basic onPointerEnter/Leave event emitting to iOS
Summary: Changelog: [Internal] Add basic onPointerEnter/Leave event emitting to iOS

Reviewed By: lunaleaps

Differential Revision: D35414116

fbshipit-source-id: dd62cf7736c466e328b9ebbf51bf010610f4bd92
2022-04-11 15:49:30 -07:00
Vincent Riemer 179c24e255 Emit touch-equivalent W3C pointer events on iOS
Summary: Changelog: [Internal] Emit touch-equivalent W3C pointer events on iOS

Reviewed By: lunaleaps

Differential Revision: D35295104

fbshipit-source-id: 1c1d5a4159bbfed92df151f7e12a4973ec44e970
2022-04-07 14:07:58 -07:00
Luna Wei c50e6b52fe Emit non-hover pointer events on Android (#33526)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33526

Changelog: [Internal] Experimental pointer event dispatching on Android: touch pointer support only, hover events to come later.

Reviewed By: vincentriemer

Differential Revision: D34132667

fbshipit-source-id: 6506d43b4ad16e11b10c3cd23e0231428209411f
2022-03-30 19:12:42 -07:00
Diego Pasquali 7b05b091fd Integrated iOS-only accessibilityLanguage prop (#33090)
Summary:
This PR fixes https://github.com/facebook/react-native/issues/30891

This PR is going to add an `accessibilityLanguage` prop to all the available components. This props is currently working only on iOS and should follow the [guidelines of the relative configuration](https://developer.apple.com/documentation/objectivec/nsobject/1615192-accessibilitylanguage).

I'm in no way an expert on native programming (especially Objective-C) so I'm open to changes / improvements 🙂

## 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
-->

[iOS] [Added] - Integrated the `accessibilityLanguage` prop to all the available components. The prop is available for any platform but it will work only on iOS.

Pull Request resolved: https://github.com/facebook/react-native/pull/33090

Test Plan:
This has been tested using both the Simulator, checking for the `Language` attribute, and using a physical device with the Voice Over enabled.

<img width="1083" alt="Screenshot 2022-02-11 at 13 17 32" src="https://user-images.githubusercontent.com/5963683/153590415-65fcb4ff-8f31-4a0f-90e5-8eb1aae6aa3d.png">

Reviewed By: philIip

Differential Revision: D34523608

Pulled By: rh389

fbshipit-source-id: b5d77fc0b3d76ea8ed8f30c8385459ba98122ff6
2022-03-07 09:43:30 -08:00
Andrei Shikov 980c52de41 Disable view flattening when the view has event handlers on Android
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
2022-02-10 06:07:39 -08:00
Ramanpreet Nara 971ba5c26b Re-introduce {eventName}: true ViewConfig ValidAttributes in Static ViewConfigs
Summary:
# Problem
I removed the {eventName}: true entries from ViewConfigs validAttributes in D33303950 (https://github.com/facebook/react-native/commit/ca5aaa766329055f206e51b2eaefcba4f282b05a). 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 (https://github.com/facebook/react-native/commit/ca5aaa766329055f206e51b2eaefcba4f282b05a) for native ViewConfigs server-side. But I never got around to reverting D33303950 (https://github.com/facebook/react-native/commit/ca5aaa766329055f206e51b2eaefcba4f282b05a) for static ViewConfigs.

# Changes
This diff reverts D33303950 (https://github.com/facebook/react-native/commit/ca5aaa766329055f206e51b2eaefcba4f282b05a) 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
2022-02-08 19:11:08 -08:00
Ramanpreet Nara 7b9490b4b1 Introduce PlatformBaseViewConfig and fix SVC for RCTView
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
2022-01-31 14:52:32 -08:00
Gijs Weterings 0c744dea56 Back out "Introduce a PlatformBaseViewConfig for all HostComponents"
Summary: Changelog: [Internal]

Reviewed By: arushikesarwani94

Differential Revision: D33042499

fbshipit-source-id: 603fbfa4e2f482c5d002532745a29170daded184
2021-12-11 06:58:07 -08:00
Ramanpreet Nara cab16352c7 Introduce a PlatformBaseViewConfig for all HostComponents
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
2021-12-10 23:19:52 -08:00