View Registry/Imperative Methods

[jacobp100]

Is there a way to invoke imperative methods in Fabric - such as <ScrollView ref={r => r.scrollTo(…)} />?

It looks like the previous method using viewRegistry no longer populates the view registry, and any related methods have names like findComponentViewWithTag_DO_NOT_USE_DEPRECATED.

What's the best approach forwards?

[jacobp100]

To clarify - I'm trying to do this outside of a component. I have a library that scrolls stuff into view: https://github.com/jacobp100/react-native-scroll-to-enhanced

[sammy-SC]

Hello @jacobp100,

I would like to explain the reason why viewRegistry isn't populated and why the use of findComponentViewWithTag_DO_NOT_USE_DEPRECATED is discouraged.
ReactTag has been a useful a concept in the legacy architecture. It allowed us to reference views across the bridge. But, it has shortcomings in the new architecture.
ReactTag assumes one to one mapping between a tag and a view. With view flattening that isn't true anymore as views might not exist. With React 18's interruptible rendering, where multiple versions of the same view can exist, it is not clear which one ReactTag is referring to.
On top of that, thanks to JSI we have an option to directly reference objects across layers. This makes it unnecessary to store a mapping between tags and views in a hash map, which has inferior performance as well.

I took a quick look at react-native-scroll-to-enhanced. Native modules are designed to allow access to host platform APIs. I don't think the aim was ever to manipulate views from within the native module. We should clarify this in the documentation but the new architecture makes this more obvious.
I'm afraid I don't have a good suggestion on how to move forward with the current implementation of react-native-scroll-to-enhanced. There are couple of approaches worth exploring:

1. JavaScript only implementation.
   <ScrollView> has a view command scrollTo which enables imperative scrolling. Measuring views is already supported but the new architecture has additional synchronous method to get layout metrics for views. I'm happy to provide more details about it if you choose to go down this route.
2. Creating a custom native component that would subclass <ScrollView>.

Hope this helps! Let me know if you have any further questions or would like me to elaborate on anything.

[jacobp100]

Thanks for the detailed response. That makes a lot of sense.

I’m thinking I might go down the route of a view that exposes the method - and scrolls its parents. I suspect subclassing a scroll view is gonna be a can of worms.

Unless RN has any appetite for a PR that adds this functionality? It’s a W3C spec, so there is precedent

[sammy-SC]

@jacobp100 I would be happy to look through a proposal that would add the functionality.

[bozaigao]

@sammy-SC In theory, the performance of the new architecture is much higher than that of the previous architecture through the JS Bridge, but in my actual test, the frame drop phenomenon occurred when sliding fast, is this normal? the issue is:facebook/react-native#33943

[sammy-SC]

I've responded on the issue.

[douglowder]

I'm a bit concerned by the future of view tags as well, as there are focus navigation APIs in the TV repo (TVFocusGuideView, nextFocusRight, etc.) where a view has another view ref (or an array of them) as a prop, and needs to get the corresponding real native views in the native implementations of these APIs. Right now, tags are the only way to do that.

[sammy-SC]

Could you elaborate on this a little bit more? I'm not familiar with how navigation APIs in the TV repo work or with tvOS. Is the navigation different from iOS/Android?

[douglowder]

Thanks @sammy-SC I'm happy to elaborate. I should probably not have used the word "navigation" in this context :) I'm referring to the fact that TVs don't have touchscreens, so there is always one on-screen view (usually a touchable/pressable or text input) that has "focus". The arrow keys or touch surface on the TV remote are used to move the focus from one button to the next one left/right/up/down. Pressing the center button on the TV remote has the same effect as pressing the touchable on an iOS/Android touchscreen.

Now, depending on the layout, the OS may not be able to identify what view should get focus next on an arrow key press (for example, if there are only two touchables that are diagonally offset). Therefore, both Apple TV and Android TV provide APIs that allow the developer to specify which view should get next focus. The TV repo has React Native wrappers around these APIs, using a view tag to identify the next focus view in the JS layer, and the native implementation gets a native view reference based on that tag.

[douglowder]

I should add that even though these APIs are only used for TV right now, the native APIs are also implemented in iOS/Android and might be needed in future to support accessibility there (similar to tabbing through a UI in web when voiceover is active). Something like this would be needed on desktop as well.

[sammy-SC]

Refer to #29 (reply in thread) from above for an answer.