Use `KeyboardController.setFocusTo` in FlashList will have limitations

[NiuGuohui]

In Flashlist, when each item in the list is an input box, I expect to be able to call KeyboardController. setFocusTo ("next") from the first input box all the way to the last item. But now we can only scroll through the first few items. Considering that Flashlist v2 actually only renders visible items, I wonder if there is a good solution?

[kirillzyusko]

Hey @NiuGuohui

I think I do a dynamic lookup, I mean FlashList/FlatList do use virtualization (they don't show invisible items) but whenever you call KeyboardController.setFocusTo("next") I'll read an actual view hierarchy again and will move focus to the next input. Maybe it's a recycling problem, that you move focus to last rendered input and on a native side it's really last element in a view hierarchy but in JS it's not?

Could you please provide a reproduction issue where you encounter a problem and attach the video to show what exactly doesn't work as expected?

[NiuGuohui]

There is respository.

I can provide an example. There may be many restrictions when using TextInput in FlashList (Shopify/flash-list#816 (comment)). However, because FlashList renders a fixed number of items and changes the position of elements through styles, KeyboardController.setFocusTo("next") cannot determine which item is the "next" one after the current item, thus causing this problem.

It can be seen that FlashList only renders a few items visible in the current viewport.This also explains why the "next" action in the video is interrupted.

untitled.mp4

[kirillzyusko]

Hey @NiuGuohui

I finally managed to find some time to look into this issue. I cloned you repo (big thank you for that!) and what I discovered is this: it looks like recycling breaks it. Take a look on this screenshot:

When you scroll down to input#9, the FlashList takes input#1 and using styles (and I think absolute positioning) moves it to position after input#9 updating its props to be input#10. I don't know how to fix this problem, because toolbar was designed to use view hierarchy to perform a navigation between inputs. But in this case view hierarchy always consist from 9 inputs, so technically when you are on the input#9 - you are on the last input.

I was also regretting, that React doesn't give you an ability to inspect JS tree (I though I can implement the traversal algorithm only once in JS), but even if JS tree would be exposed then I highly doubt it would help a lot, because from what I see in JS we will have the same 9 inputs 🤷‍♂️ So it's not a limitation of a native tool.

At the moment in my head I have two solutions:

• don't use recycling for your case (I know in LegendList it's configurable, I hope in FlashList too);
• theoretically you may use (FocusedInputEvents I use it internally in KeyboardToolbar and you can check which input is currently focus (and also how much inputs you have in general). Using this information you can check if you are on the last input AND you have a space for scrolling, then you need to set focus to first element (not to the next one). In this case you'll get a desired behavior I think.

The only thing I can think of on how to fix it in react-native-keyboard-controller is to add a "mode" property how to calculate next view. At the moment we use hierarchy, but we can also use nativeID property and search nativeID == 10 if current nativeID == 9 (but it will require you to pass proper nativeID).

Anyway, there is a lot of information - let me know what do you think about it 🙌

[NiuGuohui]

This is indeed a difficult problem to solve because the "next" is highly uncertain. Perhaps the solution you mentioned, which is to specify the input box to focus on by passing a specific nativeID, would be a better approach.