Trigger render when Animated.Event stream pauses

[j-piasecki]

Summary:

This PR is doing essentially the same thing as #37836, but for animated events instead of the animations.

The two kind of sketchy things I did are:

• To have access to the value of native Animated.Value I needed to add a no-op listener to it.
• In order to avoid re-renders on every frame, which defeats the purpose of using the native driver, I arbitrarily chose to delay the render by 64 milliseconds on every event. This seems to work okay, but I'm not sure if it's the best solution.

Fixes #36504

Changelog:

[GENERAL] [FIXED] - When a stream of Animated.Event pauses, trigger re-render to update Pressability responder regions

Test Plan:

Tested on the reproducer from the issue

[cipolleschi]

Hello @j-piasecki! I started looking into this again.

The approach works, but as you mentioned in your PR, there are a couple of not-so-clean parts:

1. the need to add a dummy listener
2. the need to use a timer.

In general we would not like to use this approach, as it triggers to many rerenders of the trees, basically one every 64 sec when events are involved.

One solution we were discussing internally was to have the source of the animation (e.g. a scroll view) to emit an event when the animation is done.
Then , the NativeAnimatedTM can emit the event to JS to retrigger the rerender. In that way we only need 1 single rerender for each user driven animation
We only have a finite number of user driven animations in Core: ScrollView scrolls and PanResponders, so we can handle them explicitly.
This approach should solve point 2.

I discovered that without the dummy listener, the approach above does not seem to work, but I can't figure out why.

This is also a part of the codebase I'm not really familiar with and as someone who spent time working on this already, I wanted to ask you:

1. What do you think about the approach?
2. Could you find why/where the dummy listener is used?

[facebook-github-bot]

@cipolleschi has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

[j-piasecki]

In general we would not like to use this approach, as it triggers to many rerenders of the trees, basically one every 64 sec when events are involved.

That's understandable, maybe 64 ms was too low of a value to actually debounce this.

What do you think about the approach?

I thought about something vaguely similar to that initially but decided not to go in that direction since it involved adding much more code than the JS-based solution I ended up with.

If the size is not a problem, then it's definitely a better approach than what I've done in this PR as it would require, as you mentioned, a single render to synchronize the native state with the shadow tree.

Could you find why/where the dummy listener is used?

I used a dummy listener as without any JS listener the animated values using the native driver don't synchronize the value with the native side (i.e. calling getValue on them will return the initial value). I guess _userDrivenAnimationEndedEvents could be extended to also update the values associated with them to circumvent this.