Change components implementation #3800

m-bert · 2025-11-04T09:48:10Z

Description

This PR changes components implementations to use new hooks API.

Warning

It requires changes in module on iOS - call createGestureHandler immediately, not adding operation block.

Test plan

Example apps

## What is happening While working on #3800 I've noticed frequent crashes on `iOS`. I'll explain this using the demo from the test code, basically two screens, second screen has a `RectButton`. 1. Navigate to second screen 2. Go back 3. Navigate to the second screen again 4. App crashes Sometime it crashes immediately on startup. ## Why is it happening? `Native` handlers are handled differently compared to others. The main problem was that we tried to attach handler that was previously dropped, but `NativeDetector` has no information that this happened. The flow here looks as follows: 1. We navigate to screen with button 2. `addSubview` is called - at this point it won't attach anything as `_nativeHandlers` is empty 3. `updateProps` is called - handlers are attached 4. We navigate back to first screen 5. Handler is dropped 6. We navigate again to second screen 7. `addSubview` is called - it tries to attach handler that was dropped, therefore app crashes ## Solution To fix this issue, we clear `_nativeHandlers` in `prepareForRecycle` method. ## Test plan <details> <summary>I've tested it on my branch with components re-written to new API, using the following code in EmptyExample:</summary> ```tsx import React from 'react'; import { StyleSheet, View } from 'react-native'; import { RectButton } from 'react-native-gesture-handler'; export default function EmptyExample() { return ( <View style={styles.container}> <RectButton style={styles.button} onPress={() => console.log('Hello World!')} /> </View> ); } const styles = StyleSheet.create({ container: { flex: 1, justifyContent: 'center', alignItems: 'center', }, button: { width: 100, height: 30, borderRadius: 10, backgroundColor: 'pink', }, }); ``` </details>

packages/react-native-gesture-handler/src/v3/createNativeWrapper.tsx

...ve-gesture-handler/android/src/main/java/com/swmansion/gesturehandler/core/GestureHandler.kt

j-piasecki · 2025-11-26T09:50:47Z

...ler/android/src/main/java/com/swmansion/gesturehandler/react/RNGestureHandlerDetectorView.kt

+    val id = if (child is ReactSwipeRefreshLayout) {
+      child.getChildAt(0).id
+    } else {
+      child.id
+    }


Why do we need that? It looks like it makes attaching to ReactSwipeRefreshLayout impossible

Can this be done in the NativeViewGestureHandlerHook?

It looks like it makes attaching to ReactSwipeRefreshLayout impossible

This should be handled by attachVirtualChildren, right?

Can this be done in the NativeViewGestureHandlerHook?

We are inside NativeDetector, so I don't exactly know what do you mean. Something like handler.shouldAttachToChild that would return hook.shouldAttachToChild?

If there's no way to get rid of it, can we get a comment explaining the "why" behind this workaround?

For now I can't see a clean way of doing it in hook. Added a comment in 7ad7ad7.

packages/react-native-gesture-handler/src/v3/createNativeWrapper.tsx

j-piasecki · 2025-11-26T10:25:58Z

packages/react-native-gesture-handler/src/web/tools/GestureHandlerWebDelegate.ts

    this.isInitialized = false;
  }

+  configure(): void {


I don't really like the name. Maybe updateListeners?

I don't like it either, but I don't think updateListeners fits here, as 2 functions inside are responsible for style, not for listening to events 😞

j-piasecki · 2025-11-26T10:28:48Z

packages/react-native-gesture-handler/src/v3/components/GestureComponents.tsx

+// Backward type compatibility with https://github.com/software-mansion/react-native-gesture-handler/blob/db78d3ca7d48e8ba57482d3fe9b0a15aa79d9932/react-native-gesture-handler.d.ts#L440-L457
+// include methods of wrapped components by creating an intersection type with the RN component instead of duplicating them.
+// eslint-disable-next-line @typescript-eslint/no-redeclare
+export type ScrollView = typeof GHScrollView & RNScrollView;


Is this trickery still needed (and also for the rest of the components)?

Yes, but in slightly different form - 5f7ec9c.

packages/react-native-gesture-handler/src/v3/components/GestureComponents.tsx

j-piasecki · 2025-11-26T10:35:18Z

packages/react-native-gesture-handler/src/v3/components/GestureComponents.tsx

+export const RefreshControl = createNativeWrapper(
+  RNRefreshControl,
+  {
+    disallowInterruption: true,
+    shouldCancelWhenOutside: false,
+  },
+  DetectorType.Virtual
+);
+
+// eslint-disable-next-line @typescript-eslint/no-redeclare
+export type RefreshControl = typeof RefreshControl & RNRefreshControl;
+
+const GHScrollView = createNativeWrapper<PropsWithChildren<RNScrollViewProps>>(
+  RNScrollView,
+  {
+    disallowInterruption: true,
+    shouldCancelWhenOutside: false,
+  },
+  DetectorType.Intercepting
+);


How does this work when, correct me if I'm wrong, Android and iOS render them in different positions, e.g.:

<RefreshControl> <ScrollView /> </RefreshControl>

on one and

<ScrollView> <RefreshControl /> </ScrollView>

on the other. I'd imagine that would also impact where the detector is rendered.

I've also thought about it for a while, but it doesn't. In case of ScrollView we have the following structure, thanks to createNativeWrapper:

<InterceptingGestureDetector> <RNScrollView>

Now, it doesn't matter which one will be rendered first RefreshControl or ScrollView - they both fall under this Detector. While React Native does change this order, it does it inside ScrollView, so effectively we have:

{/* Android */} <InterceptingGestureDetector> <RefreshControl> <ScrollView> {/* iOS */} <InterceptingGestureDetector> <ScrollView> <RefreshControl>

InterceptingGestureDetector stays at the same level.

…eComponents.tsx Co-authored-by: Jakub Piasecki <[email protected]>

j-piasecki · 2025-11-27T08:40:39Z

...ler/android/src/main/java/com/swmansion/gesturehandler/react/events/RNGestureHandlerEvent.kt

    val view = if (GestureHandler.usesNativeOrVirtualDetector(handler.actionType)) {
-      handler.viewForEvents
+      handler.hostDetectorView!!
    } else {
      handler.view!!
    }


What do you think about making this the new .viewForEvents?

I like the idea! aabc5b4.

j-piasecki · 2025-11-28T08:20:36Z

packages/react-native-gesture-handler/src/v3/components/GestureComponents.tsx

+);
+
+// eslint-disable-next-line @typescript-eslint/no-redeclare
+export type RefreshControl = RNRefreshControlProps;


Why is this one mapped to the Props type?

My bad, I've missed that. Changed in 06428d4.

j-piasecki · 2025-11-28T08:28:31Z

...ler/android/src/main/java/com/swmansion/gesturehandler/react/RNGestureHandlerDetectorView.kt

+    val id = if (child is ReactSwipeRefreshLayout) {
+      child.getChildAt(0).id
+    } else {
+      child.id
+    }


If there's no way to get rid of it, can we get a comment explaining the "why" behind this workaround?

akwasniewski · 2025-11-28T11:05:05Z

packages/react-native-gesture-handler/src/components/GestureComponents.tsx

+/**
+ * @deprecated use `ScrollView` instead
+ */
+export const LegacyScrollView = React.forwardRef<


Why do we keep legacy implementations?

We'd like to have a way for people to upgrade to 3.0 and keep their apps working as they did before. Since the new components aren't compatible API-wise with the old ones, it makes sense to keep both for the transition period.

I'd add that we do this because in that case it is easier - we want to leave old createNativeWrapper either way and those components don't have to be re-written, unlike those based on Reanimated.

I believe that's the root of this question - why Reanimated components don't have legacy versions.

j-piasecki · 2025-11-28T11:11:06Z

packages/react-native-gesture-handler/src/v3/createNativeWrapper.tsx

+    useImperativeHandle(props.ref, () => ({
+      componentRef: componentRef.current,
+      gestureRef: gestureRef.current,
+    }));


I'm not sure if this is at all useful:

It's a breaking change compared to the previous api and the components stop being a drop-in replacement - scrollRef.current.scrollTo becomes scrollRef.current.componentRef.scrollTo.

Is gestureRef actually usable? There's no way to react to changes happening to it in an easy way. It will be null after creating the ref, and that's what will be used for relations during the first render. To actually read the ref, something would need to cause a render after it's set. If it happens to change (like in the case of child remount), there's no signal that the parent (gesture) should react to it.

Ad 1. I agree that this may be a problem.

Ad 2. Isn't it necessary if we want to set relation between ScrollView and RefreshControl? For now RefreshControl blocks ScrollView, so we need that ref. On the other hand, we can't pass RefreshControl to ScrollView to wait for. I mean we could, but then we would have to call createNativeWrapper inside ScrollView component.

Am I missing something?

m-bert added 17 commits November 3, 2025 11:19

new file

dad2eaa

use native

6dbc10d

Buttons

4f1dcaa

Remove Reanimated

8ccf267

Components

df3f1fb

Add proper values to relations

a1da35a

Bring back old components

a680461

Deprecate legacy buttons

a0d0240

Deprecate legacy components

ef1e736

Export new components

563fab3

Add web file

0f40c58

Merge branch 'next' into @mbert/components-new-api

13951df

Update import

b77cc2b

use ref in check

c336453

Correct refs

c3f4320

Merge branch 'next' into @mbert/components-new-api

c6c83ba

Merge branch 'next' into @mbert/components-new-api

86c38f3

m-bert mentioned this pull request Nov 13, 2025

[iOS] Remove dropped native handlers #3819

Merged

m-bert added 8 commits November 14, 2025 17:13

Merge branch 'next' into @mbert/components-new-api

baf7eb1

Add examples

c8f7c8c

Fix buttons

2a356f8

Yet another fix

73969da

Remove Drawer Layout

f4fa5f6

Impoort hooks directly

ede51fe

remove import

d34ef86

Update examples

fdf9533

m-bert added 3 commits November 17, 2025 11:23

Merge branch 'next' into @mbert/components-new-api

38f36fe

Update scroll example

25bd430

Correctly attach NativeViewGestureHandler

4c5eaf8

j-piasecki reviewed Nov 20, 2025

View reviewed changes

packages/react-native-gesture-handler/src/v3/createNativeWrapper.tsx Show resolved Hide resolved

m-bert added 11 commits November 24, 2025 11:10

Merge branch 'next' into @mbert/components-new-api

753d43b

Import hooks directly

9b4743a

Fixes

f04d434

Update example

1f77201

Update Scroll ref

b491534

Correct web initialization

0ea974e

Remove comment

03b8a0f

Do not unpack rippleColor

5a6dc60

Remove testID

0ce2be8

Remove testID from cnw

23403fa

Disbale reanimated for components

b7c461d

m-bert marked this pull request as ready for review November 24, 2025 14:44

m-bert requested review from akwasniewski and j-piasecki November 24, 2025 14:44

Merge branch 'next' into @mbert/components-new-api

7f36f1b

j-piasecki reviewed Nov 26, 2025

View reviewed changes

m-bert and others added 2 commits November 26, 2025 18:55

Update packages/react-native-gesture-handler/src/v3/components/Gestur…

e84f3cf

…eComponents.tsx Co-authored-by: Jakub Piasecki <[email protected]>

Always assign hostDetectorView

110d333

j-piasecki reviewed Nov 27, 2025

View reviewed changes

m-bert added 4 commits November 27, 2025 16:43

Add ref types

5f7ec9c

Merge branch 'next' into @mbert/components-new-api

cff6bce

Remove handlerData

3da70f6

New viewForEvents

aabc5b4

j-piasecki reviewed Nov 28, 2025

View reviewed changes

akwasniewski reviewed Nov 28, 2025

View reviewed changes

j-piasecki reviewed Nov 28, 2025

View reviewed changes

m-bert added 3 commits November 28, 2025 19:24

Add comment

7ad7ad7

Fix type

06428d4

Merge branch 'next' into @mbert/components-new-api

a2298ef

Uh oh!

Change components implementation #3800

Are you sure you want to change the base?

Change components implementation #3800

Uh oh!

Conversation

m-bert commented Nov 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Test plan

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

m-bert commented Nov 4, 2025 •

edited

Loading