Resetting length of RG

Hello – I have a tricky question I haven’t been able to figure out.

I have a repeating group that is set to scrolling, 1 row high. Each entry contains a bunch of info, so the entry itself usually takes up the height of the page. When a user does a search, the repeating group shows around 3-4 entries, and then more appear as the user scrolls down.

The issue is that if a user scrolls to see 50 entries for example, and then does another search, the repeating group now loads a new group of 50 all at once, rather than just 3-4. Even if a subsequent search only has 5 results, with the next search, Bubble will try to load 50 all at once. It’s basically the same as if Bubble reset the number of rows in the scrolling RG to match the maximum number that has been displayed.

Is there a way to “reset” the repeating group’s # of rows?

just tested it and you are right. I use ext. vertical scrolling, it’s the same for vertical scrolling.

this is not a good news

What comes to mind is UX workaround with “show more” button but I don’t want to do that

Thank you for taking a look.

Like you I want to avoid a “show more” button, since it’s a little clunky.

This sounds like it may be something for Bubble support and possibly a bug.

Hi there, @ed727 and @bartek.dev… I haven’t tested the scenario you have described, but could the Element Actions >> Repeating Group >> Clear list action possibly help you out here? So, when the user does a new search, clear the list and then return the search results in the repeating group. Apologies if I am way off base, but the clear list action has come in handy for me on more than one occasion, so I didn’t think it could hurt to throw it out there.

Best…
Mike

Thanks @mikeloc. I believe the “clear list” function only works when the “display list” function is used to populate the RG.

I have my RG set up with the search parameters directly in it. (Specifically, the RG refers to search parameters stored in custom states. When the user hits “search” it then sets those custom states to match what the user has input, and the list updates. This avoids the list continuously updating as a user is entering in new search parameters).

I recall first starting with the display list approach, but I think the issue is it was sending everything to the RG, which negated the value of having a scrolling RG which only shows a few rows at a time. But I could be wrong about that.

I’m afraid that will count as feature request…

This does’t work for me. Clearing the list, even displaying 0 items, and then displaying the first list again uses new rows as well.

hey @ed727

did you submit bug report? if yes, what was the answer?

Bubble support was helpful in clarifying what is happening.

Basically once the the scrolling RG container expands to fit more rows, the container doesn’t subsequently shrink to fewer rows when new data is loaded.

They’ve marked this as a feature request, but I imagine this is fairly low on the list of priorities right now. Ideally a scrolling RG would have an option where you can set it to stay at the max# of rows shown so far, or reset to fewer rows when new data is loaded.

Hey @ed727,

Interesting problem. I noticed this in one of my apps too and put it down on the list of things to figure out later while moving onto other problems.

If you think the display list function could work, could you not just create an RG that is hidden from the user that takes in all of search parameters you care about, then in the RG that IS visible to the user, display “hidden RG’s list of things” every time you need to?

Hi, not sure what you mean. I think the “display list” function sends the entire search results to the RG (unless you set a limit on the # of results it sends).

That’s different than a scrolling RG, which only loads what’s needed to display on the page. In my case, I have a bunch of data and only want to show what’s needed to display on the page. Scrolling RG works for that, except for this issue where it “remembers” the most rows it has previously shown, and loads up to that point. At least that’s better than displaying the whole set of data, or having to resort to pagination.