Hello all!
I’m looking for a solution to create a responsive repeating group with pagination when using a cards-style repeating group.
I was using the toolbox plugin to generate the numbers and limiting the number of items in the RG by setting fixed numbers of columns and rows, but that’s not responsive.
Any ideas? Couldn’t find any direct answer here on the forum
Thanks in advance!
Cheers!
Are the cards a fixed size? If so install the ListShifter plugin and put the element on the page, enable pagination and do your search as the data source, then your repeating group’s data source will be the List Shifter's Shifted list. Then on the List Shifter element set the # of items per page to [your repeating group]'s width/[your card's width]:floor
Thanks @tylerboodman, appreciate!
I was trying to avoid using ListShifter for this, but definitely a solution if I don’t find a better one without extra plugins.
Do you know any workaround with vanilla Bubble features?
Yep it’s possible without plugins, you just have to do the math to determine how many pages to show, and your next/previous page buttons will need a couple workflows on each with conditionals so the page’s wrap to the beginning, etc. And set up custom states for which page the repeating group is on. You’ll need to use the [data source]:until item# [x] to limit the amount of items visible that would fit on the page
List Shifter’s pagination feature is extremely fast (way faster than if you built the math parts and related states yourself in Bubble), BTW, even given that you’re loading a couple 10K of code to your page that you’re not gonna use all of.
Also, once you have List Shifter in your page, you’ll find other uses for it (and once there’s one, there’s no penalty in adding additional ones).
Just out of curiosity what makes ListShifter operate faster than having Bubble do the math? I feel like they would both would be the same, unless you mean ListShifter is better optimized for pre-loading the next page, etc?
Workflows are not the same as native JS code. Also, updating a custom state involves publishing the value to Bubble so it takes time and is not anywhere near as fast as updating the value of a JavaScript variable (and then publishing that back to Bubble when you need it).
This is why the actions related to the Custom List and Custom Scalar states in List Shifter have an option to NOT publish the updated values (so you can sequentially or iteratively do some operation and then publish the final value at the END of the computation rather than at every step when you don’t need to be able to read the intermediate values up in Bubble).
Thanks @keith and @tylerboodman
I’ll probably follow your tips and use ListShifter.
Publishing values aside, it’s not clear to me why doing a=a+1 in JS is substantially faster than Set State some-state to some-state+1. I get the feeling that custom states are actually attached to objects in the DOM and thus have a limited refresh rate. If you watch my videos about Process List in List Shifter vs “Iterate” (and vs iterate w/o publishing the value until the end) you’ll see this quite clearly even though we don’t know the exact technical reason for it.
Try it you’ll like it.
