So I’ve got a single-page app with BDK which worked well using development mode data, but when I switched to the live data, I would encounter the app crashing (the whole app would refresh) if I scrolled down a RepeatingGroup too far. My live database has 1,200+ products a user can scroll through and that number will continue to increase, but once a user scrolls to ~ item #200 the app will crash.
I’m guessing that it is the sheer amount of data being loaded that the app can’t handle, as no workflows are occurring that would cause the crash.
Does anyone have any tips on how to minimize the amount of data loaded into a RG? Maybe a way to hide data that has already been scrolled past? Would a different type of app wrapper be better for lots of data (I’ve heard GoNative can be more reliable)?
Currently, the RG does a single search to find all products and then uses an HTML element to grab the image shown to users. Then just a simple title and product price are displayed. I have made sure not to include any “Do a Search For” expressions nested in the RG because I’ve heard that can really be taxing on the front end.
I would love to avoid that option just because it’s extremely rare to see apps with a feed use pagination, it just doesn’t feel like a native app experience. But that may be my only option so I’ll have to consider it.
Yeah I hear that! More of a brainstorm thought here but could you look into hiding the cells that are out of view? So instead of scrolling down a list, your repeating group acts more like a conveyer belt - as the user scrolls, it’s only loading the cells they can see (and a couple on either side)?
Your best bet is to reach out to @gaurav directly through thebdk.com. He’s usually pretty could at responding.
Also just a thought, the chances someone will stroll through all 1200 items is probably quite rare. Also, if someone has to stroll through that whole list, this it probably isn’t the best UX. One approach would be creating a UX that prompts the user to give you some filter parameters first and then search through that more constrained list.
Also, make sure you aren’t doing any client side filtering or sorting. This will force Bubble to bring the whole list to the client and probably increase your odds of crashing.
That would be a good solution, not sure how I could pull off hiding the cells that are out of view though. I’ll take a look through the forum and see if I can find anything.
Definitely unlikely someone goes through all 1,200 but 200 is likely just because it’s a feed of products for collectors so they may love scrolling through a bunch of items. Good call about avoiding client side filtering though, I actually have a server-facing filtering function on the site which seems to help the performance a bunch. Appreciate the response!
