`onScroll` on `KeyboardAwareScrollView` is not fired

[kirillzyusko]

Describe the bug

onScroll on KeyboardAwareScrollView is not fired

Code snippet

Just add onScroll={console.log} in example app.

Repo for reproducing

You can use example app.

To Reproduce
Steps to reproduce the behavior:

1. Go to KeyboardAwareScrollView
2. Scroll view
3. See console output

Expected behavior

You should see events if you scroll ScrollView.

Smartphone (please complete the following information):

• Desktop OS: MacOS 14.2.1
• Device: iPhone 15 Pro
• OS: iOS 15.2
• RN version: 0.72.4
• RN architecture: old
• JS engine: Hermes
• Library version: 1.10.2

Additional context

It can be fixed by adding next code into onScroll handler:

const onScroll = useAnimatedScrollHandler(
    {
      onScroll: (e) => {
        position.value = e.contentOffset.y;

+        if (onScrollProp) {
+          runOnJS(onScrollProp)({ nativeEvent: e });
+        }
      },
    },
    [],
  );

or assign our onScroll handler as onScrollReanimated (REA intercept all events for a given view, so there is no difference which prop to use).

[z1haze]

This is not fixed. onScroll does NOT fire from KeyboardAwareScrollView. @kirillzyusko please reopen this. I even pulled in 1.10.3 which was the version that supposedly fixed this issue to make sure it was not just a regression. It remains broken on that version, too.

[kirillzyusko]

@z1haze thanks for bringing it up 👀 May I kindly ask you to test #408 and see whether it fixes the problem or not?

I believe it should fix because I just tested example app and had the same issue as you - and this PR resovles the problem. But I'm more than sure that previous approach was working - most likely with a new release of RN or REA it's not working now, but again it was working before 👀 😅 .

[DaltonPelkey]

Hey @kirillzyusko. Checking your solution, would it not be more effective to use a normal scroll callback?
This is my current patch for it:

    const onScroll = useCallback((event:NativeSyntheticEvent<NativeScrollEvent>) => {
      position.value = event.nativeEvent.contentOffset.y;
      onScroll2?.(event);
    }, [onScroll2]);

Is there an underlying purpose for using the reanimated hook for the callback?

Edit:
To add more context. I replaced the onScrollReanimated mystery prop you were using with onScroll

[kirillzyusko]

Is there an underlying purpose for using the reanimated hook for the callback?

Yeah, it will update the value on UI thread synchronously. In your case it'll be updated on JS thread and it will not be as efficient as updating on UI thread.

Potentially it's possible to use your solution (I am reading scroll shared value only when keyboard movement happens - that value is not driving any animation, so it's okay to miss some frames during update), but of course I need to check that there is no performance hits 😅

[DaltonPelkey]

That makes sense. I originally tried the runOnJS solution, but I think it wasn't working correctly because the scroll handler from props needs to be passed to the useAnimatedScrollHandler deps array. My callback wasn't being updated with its own dependencies for that reason, I think.

Aside from that, if the regular callback works, it seems less "hacky" to do that since you can pass the entire event rather than just the nativeEvent properties.

[kirillzyusko]

Aside from that, if the regular callback works, it seems less "hacky" to do that since you can pass the entire event rather than just the nativeEvent properties.

Yeah, for sure 👍 I changed a code in my PR - would you mind to test it and confirm whether it fixes the problem in your project? 👀

[DaltonPelkey]

I've been using the JS implementation since this morning. Everything seems to be fine. My only concern was that it would mess with something since it is not longer using Reanimated's hook. I also wasn't sure what was going on with that mystery onScrollReanimated prop.

[kirillzyusko]

@DaltonPelkey onScrollReanimated is an internal prop and was used to intercept onScroll event 🙂 So it shouldn't be a breaking change.

My only concern was that it would mess with something since it is not longer using Reanimated's hook.

I think it shouldn't. And you are right - this implementation looks less hacky so let's try this 👀

I'll merge PR tomorrow 👍

[z1haze]

@kirillzyusko we could not find anywhere that prop was being used. Could you shed some light on that?