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.