Calling JS methods from Host Platform

[troZee]

Description

While porting react-window library into React Native, I noticed onScroll method in ScrollView component was not called so often on LE android devices. I was trying to change scrollEventThrottle prop, but it did not helped.

I decided to implement custom scrollview to speed it up and when I used this approach it increased number of onScroll method calls.

Reproduce

• add logger here
• add logger here

You should be able to see logs as follow:

I/ReactNativeJS: '🚀🚀🚀🚀🚀🚀🚀🚀 ', onScroll called on JS
D/: onScrollChanged: has been called on native side
D/: onScrollChanged: has been called on native side
D/: onScrollChanged: has been called on native side
D/: onScrollChanged: has been called on native side
D/: onScrollChanged: has been called on native side
D/: onScrollChanged: has been called on native side
D/: onScrollChanged: has been called on native side
D/: onScrollChanged: has been called on native side
D/: onScrollChanged: has been called on native side
D/: onScrollChanged: has been called on native side
I/ReactNativeJS: '🚀🚀🚀🚀🚀🚀🚀🚀 ', onScroll called on JS

Expected Result

onScroll method should be synchronous

Questions

• Does this approach use JSI ? or still it uses old bridge
• There are any plans to generate JSI methods, which will call JS code from native code via codegen ?
  The api would look in the same way like for commands ?
• Have you got any plans to improve ScrollView onScroll callback ? if yes, how I can help you with that ?

[NickGerleman]

Hey @troZee,

The onScroll event is coalesced, meaning instead of delivering many events, when the JS thread is busy, it will only deliver the most recent scroll. This is by design, to avoid the UI thread firing many events that the JS thread does not keep up with. When this happens, the JS thread would waste time doing work on a scroll position that is out of date, instead of the most recent one. You can see an example of why this is important for performance at microsoft/react-native-windows#7260

So the expected behavior is that onScroll will be fired at most once per frame, but it may be fired significantly less often if the JS thread is busy with other work.

[sammy-SC]

I'll just add that there is a prop scrollEventThrottle which you can use to control how often the event is triggered.

[troZee]

It did not helped in my case. I unmark this as answer, since probably I explained my issue in wrong way and it did not answer on my question. I agree, that events must be coalesced to avoid additional unnecessary computation. I was playing with scrollEventThrottle and it did not help in my case. I did a little experiment once again for each throttle value:

scrollEventThrottle = 0 

onScrollChanged: called 266 times on native side 
onScroll: called 7 times on JS side 

scrollEventThrottle = 16

onScrollChanged: called 266 times on native side 
onScroll: called 3 times on JS side 

scrollEventThrottle = 32 

onScrollChanged: called 266 times on native side 
onScroll: called 2 times on JS side 

When I registered a onScroll method in the bridge, I was able to see this method called in synchronous manner.

My question is, if there is any plan to call onScroll (or other events) methods using JSI ?

[thymikee]

Should we expect scrollEventThrottle = 0 to pass all the scroll events to the UI thread or is it bound to frame rendering and it's impossible to do so?

[sammy-SC]

@thymikee
yes, all events in the new architecture are passed through JSI. But that doesn't change how onScroll is throttled. JSI is a more efficient way to communicate between JavaScript and host platform but does not affect throttling.
There are two layers where onScroll event is throttled. One is on the host platform side where host platform informs about all scroll events but they get throttled by scrollEventThrottle prop.
If it is set to 0, all events will be scheduled to be dispatched to JavaScript. The events are in queue waiting until JavaScript thread becomes idle and can process the events. For onScroll event, only the latest event is stored in the queue. Not all recorded events are dispatched to JS because it would be wasteful. Only the latest JS event is relevant. We refer to such events as continuous and it has implications on how React prioritises updates from events of this type.

I hope this clarifies how throttling of onScroll works. Let me know if anything is unclear.

[troZee]

Hey @sammy-SC
Thank you for an explanation.

[thymikee]

Hm, isn't it too soon to accept the answer @cortinico @sammy-SC? I find @NickGerleman comment pretty insightful. However there's no answer to these:

1. whether using https://github.com/petterh/react-native-android-activity#android-calling-javascript-from-java is valid in new architecture or there's a better way to do this? @troZee is asking, because we could use it for one library we're researching, but we're not sure whether it's ok to do so.
2. Are callbacks (like onScroll) leveraging JSI already or not really? Can we consider the callbacks being synchronous in any way, or are they always async?

[cortinico]

isn't it too soon to accept the answer?

I'm not sure I follow you as here the answer is not 'accepted'

[sammy-SC]

My apologies @thymikee. I prematurely marked the response as answer as I thought it was sufficient :)

1. I don't know the answer to this one.
2. Yes, all events in the new architecture are leveraging JSI already. Right now, all events are asynchronous even in the new architecture. This is for backwards compatibility. The new architecture gives us flexibility to break out of the old async model but it is not leveraged yet. It gives us a way to achieve performant synchronous rendering. You can read more about the threading model if the new architecture here: https://reactnative.dev/architecture/threading-model.

[thymikee]

Thanks! I thinks I'm good with those answers. @troZee how about you?

@cortinico I meant this course of events

Typically I'd expect the person that asks the question to mark whether something is accepted as an answer or not, but I can understand how this may be blocking some actions from your side as well. I also noticed that "answered" word is quite ambiguous in this context (question can be answered, but may not be fully resolving the problem/question). Hope GitHub would change it to "accepted" or so :D

[sammy-SC]

We don't have a policy about the use of "answered". It is not blocking anything on our side, it is purely about bookkeeping. I certainly do not mean to discourage people from asking more questions.

[troZee]

My apologies @thymikee. I prematurely marked the response as answer as I thought it was sufficient :)

1. I don't know the answer to this one.
2. Yes, all events in the new architecture are leveraging JSI already. Right now, all events are asynchronous even in the new architecture. This is for backwards compatibility. The new architecture gives us flexibility to break out of the old async model but it is not leveraged yet. It gives us a way to achieve performant synchronous rendering. You can read more about the threading model if the new architecture here: https://reactnative.dev/architecture/threading-model.

Thank you for detailed answer. I was thinking, how we could improve the ScrollView component to utilise new architecture better, but since a backward compatibility we cannot do anything more.

[troZee]

Per @sammy-SC

Yes, all events in the new architecture are leveraging JSI already. Right now, all events are asynchronous even in the new architecture. This is for backwards compatibility. The new architecture gives us flexibility to break out of the old async model but it is not leveraged yet. It gives us a way to achieve performant synchronous rendering. You can read more about the threading model if the new architecture here: https://reactnative.dev/architecture/threading-model.