Another Repeating Group Optimization Question

twowheelsanddeals · 2025-03-25T19:55:20.711Z

First, thank you for taking a look, it really means a lot.

App has repeating group displaying all types of clothing articles.

Is it best to have:

A single repeating group that searches for all articles of clothing and with use of filters, simply collapses and hides unwanted cells. This way the repeating group is only loaded once and does not have to keep fetching data every time filters are changed.
A single repeating group that has filters. The filter button simply changes what articles of clothing the repeating group is searching for. This loads less data at once however data fetching will happen every time filters are changed.
Multiple repeating groups. Each repeating group only displays one type of clothing. Filter buttons simply collapse and hide the other repeating groups.

4 Some other clever way of filtering the repeating groups that you know of?

Thank you all once again, you have no idea how helpful you are.

rafael.tgt · 2025-03-25T20:36:34.231Z

I would use option 2 - A single repeating group that has filters
put the filters directly to the search constraints (mark the checkbox "ignore empty constraints) - the bubble’s fetch time, in this case, is very acceptable

I see the idea behind loading it all once and keeping it hidden, but it can increase the page size and load time as the DB grows - and any DB update can trigger cascading updates on the page.

But if you know this DB won’t grow exponentially, you can load all data in a hidden RG (like inside a popup that never is opened), and then you create your RG on the page using the hidden RG’s list of items - and then add a :filtered expression to filter based on your filters

ademiguel · 2025-03-26T12:02:24.862Z

I agree with @rafael.tgt that the option you choose depends on these factors, related to the amount of records retrieved by a Do a search for expression.

How many records you currently have in DB?
How many records you expect to have in the future?
How heavy are those records?
How complex are RG’s cells? In terms of HTML elements per cell and nested searches, if any.

All those factors affect to page load time (and therefore SEO ranking, UX…). It’s a matter of trial and error to set a limit on how many records can be loaded at once before any metric you’ve defined goes bonkers.

Now, even option 2 can lead to problems if no filters are selected and just all records are retrieved. The most secure way to protect UX against tons of records being retrieved is using RG pagination.