Does NativeScript-Vue implicitly render each ListView cell into a StackLayout/ContentView, or is it a floating tree?

We're only rendering whatever is inside the v-template no extra wrapping elements are created. NativeScript requests views through the onViewLoading event, and if we don't have a certain template rendered yet - we create it, otherwise we just patch the existing views with new data.

I'd be curious to see your findings @tralves based on what @bradmartin suggested on Slack.

I wonder if for some reason the patching doesn't work properly in some cases, and re-creates views. I'm also curious to know if this is specific to the latest version, or has it always been like this? I haven't had issues with the LV performance so far. In the app I'm working on, we have around 15 v-templates, and has been working fine, although not that many elements.

@bradmartin suggestions on slack were not very conclusive. For some reason, the performance of the ListView in the NS-Vue project built on my machine was better than the one from the playground... ¯_(ツ)_/¯. Anyway, the problem is more noticeable on iOS, probably for the dynamic heights.

Has anyone tested the projects in the playground? Do you see the same sluggish scroll?

I also checked the native components tree and they were the same. No problem there.

The next step is to check the patching and re-creation of views.

The LV has always shown these issues since I started the project, almost 1 yr ago...

@rigor789 I found that at onViewLoading, args.view is always null when we have more than 1 <v-template>s.

So for some reason, the listview is not giving NS-Vue a view to be recycled. I am trying to figure out if the ListView templates are being set correctly, but as far as I can see, they are.

Any ideas?

It turns out that this is only reproducible on iOS with NS-Vue with multiple templates*:

• On Android, the views are recycled properly;
• On NS-Core, the views are recycled properly;
• With just one template, the views are recycled properly;

I also tested reverting the commit ba4e994, but it didn't fix anything.

So the error must be in the way the templates are passed to the UITableView when using NS-Vue... which doesn't make much sense...

I am searching for more clues on the way the NS creates the native components, but right now I don't have any more ideas...

*- I tested this by attaching itemLoading events to the ListView and loaded events to the components inside the LV templates. The itemLoading triggers when each cell item is rendered but the loaded is only triggered when the actual content is created. On NS-Vue iOS, I see one loaded for each itemLoading, meaning that new components are being created for each cell. On Android/NS-Core, I see a bunch of cells being created at first, but then only itemLoadings.

I was curious as to whether the ListView was slow just because of the limits of on-the-fly reconciliation and re-rendering (regardless of UI renderer), so I ported it to React NativeScript.

https://play.nativescript.org/?template=play-react&id=844mww&v=14

But... it scrolls pretty fast on iOS by my eyes 😅

thank you for the test, @shirakaba! You are right, it works fine on React NS...

(I secretly wished it didn't because Vue is bae and then there would be more people looking into it 😛)

I dont see that issue in my nativescript-collectionview plugin. At least I don't think I do... May be we can try to recreate the example with it and compare. I know I don't handle templates the same way

I found the issue! (eee the PR above).

For comparison of a before/after, see the updated playground app. The list on the right is patched with this fix.

Thanks to everyone here helping me turning to the right direction. Peeking at @shirakaba's React implementation was key, though!

We are locking this issue because it has been closed for more than 14 days.

If the issue comes up again please open a new issue with additional details.