Switching between repeating groups rapidly (Performance)

I have nested repeating groups (Lists > Groups > Tasks) - For a task management platform. The user can click the list which then loads the groups of tasks (and their tasks). When they click a new list, the repeating group loads the groups and tasks of the new list.

It’s extremely laggy when switching between these. Is there a better way I can organize this? Is there any clever ways to preload data in states or anything and pull the information from there rather than contacting the database? Or maybe creating a repeating group for each list and hiding them rather than using the same repeating group and repopulating each time they switch lists?

Any advice?

My philosophy is to first see if the root issue (laggy loading) can be fixed. If not, then you can look at a band-aid (which probably is creating a hidden RG to hold all the data, and then the results RG pulls from that).

Re: why your data could be laggy, it’s usually a slow client-side search filter; or datatypes that are “heavy” with a lot of data (bubble downloads all the fields of a datatype, not just what’s shown).

1 Like

Thanks @ed727 for the reply. I’ll look into seeing if I can fix the root cause before trying the “band aid” approach as you described it.

Out of curiosity, do auto-bind elements in a RG affect the performance at all (compared to only using non-binded elements)?

I don’t know (because I don’t use auto-bind), but I wouldn’t be surprised if they do. I avoid auto-bind, and instead let the user fill out fields and then hit “submit”, then the workflow writes all the changes at once. I do this because a) it reduces mistakes from someone typing in the wrong thing or deleting a value, which then over-writes the correct value with no way to revert; and b) it groups all changes into 1 workflow, rather than Bubble trying to “keep up” with changes being put in piecemeal.

I take the same philosophy with user searching – the RG is filtered based on custom state values; the user fills in the fields, hits “search” and then a workflow writes those fields into the custom state and the RG filter kicks off. That’s only 1 workflow and database call, versus multiple ones.

PS: in addition to various great posts on the forum about speed issues, this book is a great guide: The Ultimate Guide to Bubble Performance - the new edition is out (now 210 pages!)

1 Like

Sweet! That’s awesome. I bought that book about a year ago :grin: It’s awesome a new version is out - I’m looking forward to reading it. Shout-out to @petter for hosting a stellar bootcamp too.

Your suggestions are my default choices too - Thank you for describing that process - this is super valuable for all that read this post. Right now I’m working on a specific app where auto-bind makes sense as a UX component but also it was requested by the founder who I’m making the app for. A significant enough performance impact with auto-bind in RG could revise that requirement though.