Visibility Property is your enemy while dealing with lists!

1

It took me around 20 months of developing in AppGyver to disuade myself of using the visibility property in rendering lists.

The screen tips on the visbility property in composer say that items that are not visible won’t be “rendered at all”. That sounded to me like it meant they won’t take up processing time or memory, etc. Well, that’s utterly false. While that may be obvious to those more tech savvy, to me it wasn’t.

Visibility is useful for hinding single components but deadly in hiding items you don’t want to show in a list, especially if the list grows and can become long.
I recently found that:

Loading a data variable with hundreds of records is fast.

Getting hundreds of records from storage is fast.

Hiding or showing the records with visibility is fast.

But REPEATING components with hundreds of records (the repeat-with property) can take a VERY LONG time. Disproportionally.

So why is visibility the enemy? Because it lets you think you CAN repeat hundreds of items painlessly, just hiding most of them. If the user doesn’t deliberately choose to see hundreds of records at once, you should show them just a few and let them choose to expand the list if necessary. But never use visibility for that. Repeat less items. Don’t make them invisible!

Displaying a long list that hides 580 items (“not rendered at all”) and shows only 20 items takes several painful seconds of loadtime. Displaying a long list while repeating only the 20 first items is fast like you expect it to be. Not knowing this could ruin a project altogether.

I wish someone told me that when I started.

Or that the screen tips in composer didn’t mislead me like they did! AppGyver team, please fix that!

PS: Sure, visibility is useful to hide components inside items that repeat. But that’s a whole other story.

2 Likes
2

And so for that, one should use the Paging option here:
image

2 Likes
3

I also noticed this, although did not test it thoroughly.

I found a good method of dealing with this is using another variable to store ‘what the user wants to see’.
In my case it was a table, I stored the entire list response in a variable, then a filtered subset in another variable (based on user selection, searching, and sorting).
Finally after adding pagination I stored the current ‘batch’ based on the page index, which would only contain up to 50 items, and this would update dynamically as the user clicks through which made big improvements in performance.
(this was all handled by logic)

The other thing you could try is putting a formula in the Repeat With component, and this formula could be set to use a SEARCH / FILTER function or something similar - without knowing your case exactly, this could remove the items you don’t want to see which might make some kind of performance improvement?
I’m not sure on this case, but using the same formula inside the logic to set / filter a variable and repeat over that var instead should definitely make a difference