Hi- I’m trying to create an infinite scroll experience on my mobile view, but an RG with a search function is pretty WU-costly.
Is there a particular setup I can do to optimize on WU?
You can use pagination to not load aa data with filter options use to select
sorry- still very new to this. Could you elaborate please?
Pagination on a repeating group will not give you the infinite scroll that you want. The pagination gives you “X” amount of results and then at the bottom of the page are page numbers that you click on that give you another set amount of results. Much like Craigslist results are.
I too am trying to figure out the cost effective way of infinite repeating group. I just posted a question in the forum a few topics after your question. Maybe you can gather some info from that and then hopefully someone better than me will tell me what would be the most effective way to fetch data.
Good luck
i’m not sure if this is IT but seems to be automatically built in with ext. vertical scrolling:
How to Create Ext. Vertical Scrolling With the New Responsive Engine | Bubble
All you need to do is uncheck the option “show all items immediately” on the RG. This will effectively “chunk” the data and retrieve only what can be displayed (plus a few extra items to improve the user experience).
Optimising the WU is a tough one - but one thing to consider, if this is expected to be a heavily used page - is create a separate data type just for that page, with only the absolutely essential data included in it, and use that for the RG. If the user needs to view more detail, for example, include a field in the datatype to the associated “detail” data type. In the new data type you create, the fields inside that table could then just reference other data types, or even better - have a unique copy of the essential data only, as this reduces the WU further, since only a single data type must be queried. In the database world, this concept is called “de-normalising” and is usually applied for performance or efficiency reasons.
I should also mention - if WU is a serious concern for you (e.g. you are developing a B2C app that could have lots of non-paying users) - consider hosting your database backend on another platform like Xano, and use client-side plugins to pull data from the data source. Implementing “infinite scroll” in this case would be a bit more complex, since you would need to implement a pagination capability - but it can be done, and will be nearly free from a WU perspective.
i have a similar implementation but it has a “load more” button instead of automatically loading the next page as you scroll down. maybe the logic behind the “load more” button can be tweaked to work for you.
what i did is to use two RG’s. RG1 (displayed posts) is not hidden and RG2 (queued posts) is hidden.
RG1 data source is empty.
RG2 data source has the search to pull the set of records per page.
i also have “update list and states” custom event. that is triggered once on page load event, and triggered every time “load more” button is clicked.
this custom event has two actions:
-
merges posts in RG2 to RG1.
-
update the pagination parameters. these parameters are custom states (i.e. until, from, offset)
lastly, i have the “post detail” group under the “posts listing” group (pls see first screenshot). each post title in the listing, on click, has a workflow that hides the listing group and show the detail group. then on the detail, there is a “back to listing” button, that hides the detail group and show the listing group. so this process does not trigger page reload and avoid doing a search to show the listing back. and i think this helps to optimize WU.
i’m new to bubble and still has little amount of data in the db. so my implementation may need some adjustments. if so, kindly let me know.
[edited] here is the screenshot, offset is set to 3 (i.e. three posts per page).
I am not sure if this option just prevents renderization, but not data retrieval. In such a case it wouldn’t be a solution for the WU savings.
If so, a solution would be a dynamic update of RG data source, limiting the search to N elements, expanding N as user scrolls.
Well… it does
1 Like