In my app a repeating group takes 3-5 seconds to load 100 rows of content - increasing the page bounce rate.
To get around this I’m currently limiting the app to show the first 15 rows on load and then allowing the user to ‘Load More’ by clicking a button and showing the 100+ rows.
I wondered whether it would be possible to get the app to background load the full table or load cells only on view (similar to when infinite scrolling is enabled in a repeating group).
In addition, I would also have a look at your data and what you are searching / sorting on.
It is very unscientific, but I end up de-normalising sort fields so they are in the main data type and a primary field, the aim is to avoid relationships and counts.
I’m having the same problem here. Many of us in this forum have mentioned that we want to build a chat function. In order to do this, we’re forced to load the repeating group and focus on the most recent entry. Unfortunately, this means that everything has to load in order for the most recent chat to be seen.
Right now, the focus doesn’t go to the last item when the repeating group has more than 100 entries.
Given that my company is chat based, it may end up being a make-or-break for whether we can continue with Bubble. Are there plans to fix this?
@emmanuel - how much would it cost to sponsor a repeating group that loads “upside down” (Like a typical messenger app: From the bottom up.)? I would imagine this could fix the issue. That way, if they wanted to scroll up to load previous messages, they could, but it would load the most recent message lighting fast.
@Lucien Thanks for sharing your example! I’m working on something similar–a texting app–and the simplicity of your approach was very helpful in many ways.
Quick question if you don’t mind? No rush on this, whenever you have a chance. Apologies in advance for hijacking this thread.
Can you explain the scrollbar html header? i don’t know html/css. I see the two webkit-scrollbar entries. Just wondering what each does/why each is required.
I’ve read many discussions here on hiding scrollbars. Your solution is the best I’ve seen!
For the HTML header, it’s just a cosmetic addition. You don’t need it (but you might want it). The purpose is to hide the scrollbar of the repeating group that can appear with some browsers (or when you’re in incognito mode on Chrome apparently).
I found that small piece of magic code somewhere on the forum but I can’t remember which thread. Some variations of it allow you to control the style of the scrollbar if you prefer.
@Lucien – Thanks! Your solution is awesome and does help a lot… although have you noticed that when the repeating group contains lots of messages (more than 20-30 or so), it struggles to load & scroll quickly? Just doesn’t feel like a crisp messaging app. Feels a bit clunky. Maybe it’s just that I need to purchase more server capacity, not sure. Will test that.
Hi, has this been fixed? I think we still have to work with the “scroll to” last entry - but surely not crisp and the user experience is not great as it “struggles” to lead everything if the chat is big…
code somewhere on the forum but I can’t remember which thread. Some variations of it allow you to