angular 2 proper way to handle long list filtering

[Krzysztof Szczesny]

Hello,
I'm trying out angular 2 on a small app that displays a long list (1000+ items) and allows multiple filtering.
The thing I'm wondering about it how to properly handle this scenario for optimal performance.
I've tried 2 approaches
1) filter the data source and refresh the list bound to *ngFor each time the filter changes
2) use display:none for each item that doesn't pass the filter

The first approach seems to leave the UI a bit more responsive (you can modify the filters before the filtering is done - so the controls don't "freeze") but takes longer to process.
The second approach is faster in terms of producing the final result, but as the filter is applied, it doesn't allow modifications until the rendering is done.

My question is, what's the recommended/proper way to handle this scenario?

Some additional info to provide more context.
The filters consist of 2 kinds of controls - text inputs or buttons. Buttons represent 'categorized' values, text inputs filter by specific object properties, though I'd like to have a single input that filter on multiple (but predefined) properties.

In the first approach I'm performing 'raw' filtering on an array. Not using an observable here (though considering it, how much and what would that change in terms of performance?)

As for my current findings, the obvious reason for the first approach being slower is multiple DOM operations - every time the data source changes, the DOM is rebuilt by *ngFor. Are there any non obvious reasons why this slows down?
The second approach does not create any extra DOM insertions/deletions, but it does cause multiple repaint/layout (?!?) operations done by the browser. Is there a way to delay these?

Any insight on the subject is appreciated.
Thanks in advance.

[Sander Elias]

Hi Krzysztof,

The best approach would be, 1, but combined with paginating. Just show the first 20 to 50 rows, and then paginate over the rest (If needed, your filter/sorting should put the needed data on top of the list anyway!)

(also, you can use an "infinite" scroll instead of paginating, but this is a tad more complex to do.)

If you want to give the user some feedback on the number of results, just put that in your app. I mean it literally put it in, or just above, your list. Something like "results 1 to 20 off 123045"

Regards

Sander

[Krzysztof Szczesny]

Hello Sander,
Thanks for the tip, but paging is not an option. The app is a port to angular 2 of this http://spooky.github.io/unitdb/#/ (which is in angular 1). Paging is kind of the question in terms of UX ;) Currently the list has 406 items, but this will grow to (s I mentioned) around 1000+ items.

[Sander Elias]

Hi Krzysztof,

Can you show me a real UX study that favours a huge table instead of a paged one? I have read numerous science based ones that favour interfaces with fewer items available.  Humans seem to have a problem processing UX with more as 200 items in it. 

I'm really interested in this, perhaps minds have shifted!

Regards

Sander

[Krzysztof Szczesny]

Ah sorry, noticed a typo in my previous post. I meant to write "Paging is out of the question in terms of UX" (for this case <- that part was implicit). Not sure if you clicked the link or not, but that app doesn't have a normal table - it's a collection of pictures...for gamers....for a game in which having 500+ units is a normal thing, so I'm fairly certain that users don't have a problem with too many items on the list. At least I haven't had any complaints in that matter.

[Tito]

could this help. we did something similar for an stock photo site but not with angular. requirements was no pagination but infinite scrolling

https://sroze.github.io/ngInfiniteScroll/

[Sander Elias]

Hi Krzysztof,

Ok, I now have taken a look at your UX, looks good to me. Still, you can use infinitive scrolling, but I guess in this case that would be hard to implement, and not really adding much performance.

I didn't look at your code at all. The performance was quite alright on my system, but that's not really helpful. (developers tend to have hefty machinery;) ). I don't know if you used the trackBy option? That would help.

If you did, and performance is still subpar, We can have a look at your actual code, and see what's the best way.

Is some cases, a bottom-up approach is the fastest. Let each 'item' toggle its own visibility. (by directly manipulating the DOM, without angular involvement)  

To answer your question about observables. They will do nothing for your  performance. Perhaps make it a tiny bit slower even. (adding an abstraction layer tend to do that, it's just extra code that needs to be run)

They will help in simplifying your logic. Making it easier to reason about.

 Regards

Sander