CODEWITHSUNDEEP
angularnativescript
SeanRtS
SeanRtS

Reputation: 1205

Is *ngFor stable for lists in Nativescript Angular?

Edit: I have asked a related question about what the current state of RadList View is (does it exist anymore?) here.

Original question: Is *ngFor ok to use for lists in Nativescript?

Normally, I find people recommending RadListView, but for ease of use and being able to customize the list, I strongly prefer *ngFor. However, I recently had a few glitches using *ngFor, so I want to be sure it is stable in the most recent Nativescript.

Details:

In my iOS app, built with Nativescript, I have a few two level lists--lists with categories and then items in each category--like:

-People
---Joe
---Suzy

-Animals
---Fito
---Spot

-Places
---Park
---Town

I originally tried to build this type of with RadListView from the Pro UI, but I found building a two level list overly cumbersome. I need to be able to load and then manipulate the data in various ways, and it seemed like RadListView was made for limited customizing.

This discussion mentions the "grouping function" as the way to do it with RadListView, but that was an inflexible approach for the type of data I have. Using basic ListView was even worse in terms of inflexibility and customizability.

So I have been using basic *ngFor, like:

<StackLayout>
    <StackLayout *ngFor="let item of things">
        <Label text="{{item.type}}" (tap)="clickToShowEntries()"></Label>
        <StackLayout *ngFor="let entry of item.type" style="margin-left: 80px">
            <Label text="{{entry}}"></Label>
        </StackLayout>   
    </StackLayout>
</StackLayout>

Is there a problem using *ngFor instead of RadListView? After updating to the most recent Nativescript and CLI, the list on my app didn't seem as stable--a few times in testing some of the categories overlapped with each other randomly and the screen was glitchy. I have not reproduced that error, but it made me wonder whether there is a problem using *ngFor.

Upvotes: 0

Views: 1018

Answers (2)

SeanRtS
SeanRtS

Reputation: 1205

I will leave @Nick Lliev's answer as the accepted answer, but I wanted to note: I have discovered why *ngFor appeared "buggy" for iOS after upgrading to Nativescript 5.0+. In Nativescript 5.0+, it looks like the team made some changes to make Nativescript work better for iOS's safe area. This affected the style/formatting of items like *ngFor.

In my case, after the ugprade, *ngFor lists that used to work perfectly started doing buggy things like having random large white space on the screen, and entries overlapping.

I was able to correct this by adding iosOverflowSafeArea="false" as a header in my html (like <StackLayout iosOverflowSafeArea="false"...). With this change, my *ngFor lists seem to be back to normal.

In fact, in testing on my device, my *ngFor list work better than my RadListView lists with grouping function. The *ngFor lists are perfectly smooth, while the RadListView lists are a little jerky in the scrolling. Both lists have same amount of data--around 40 entries. Anyone know why *ngFor might actually scroll more smoothly than RadListView?

Upvotes: 0

Nick Iliev
Nick Iliev

Reputation: 9670

ListView and RadListView are components that are using the native approaches for handling lists. Both are using recycling and virtualization (check this blog post for details) which are greatly improving performance. Both ListView and RadListView are supporting multiple templates and customization and even more - they are aligned with the mobile APIs as behind the scenes there are native elements that are creating these components.

The Angular's ngFor is a structural directive that is not optimized for large lists that will be loaded on a mobile device.

So the short answer is to use ngFor only for short lists and ListView / RadListView for anything that you might consider heavy.

Upvotes: 1

Related Questions