Rank by category using current cell index

Hi Guys , I have a database that tracks a “Product/Solution” by overall rating , and then ranks them from the highest overall rating to the lowest ,

because the amount of fields is a bit much , I have resorted to using a fixed number of 5 rows i.e to show 5 Solutions per page , I am using some filter types that sorts the Solution Category and ranks the top , so i am using current cell index to show the top 5 . #1 #2 etc ….

but now when i click on next to show next page , it refreshes the repeating group and go to other solutions as intended but the current cell index reverts back to #1 -5 rather than starting from the next which is #6 … How do I get this to work pls .

NB: I know current cell index always starts at 1 inside each page of the repeating group.
So when I go to the next page, Bubble starts indexing again from 1 “

what could I do to make it work using the Next and previous but but to show 5 solutions only

I have used “Current cell’s index + (RepeatingGroup’s List of Solutions:first item’s index - 1)” but it does not work - it shows #5 #10 #15 @georgecollier @boston85719 Kindly help , I have also searched the forum to check any possible solution. Thank you

You don’t want to sort by Current cell’s index—that value only exists inside the cell after the list has already been sorted and paginated, so it can’t drive the order. Sort the repeating group by real fields (e.g., Overall Rating descending, plus a tie-breaker like Created Date or Unique ID for stability) and use Current cell’s index only to display the rank number.

For continuous numbering across pages, add a page offset to the index. If you’re using the RG’s built-in pagination (Show next/previous with 5 rows), display: Current cell's index + ((RepeatingGroup’s current page - 1) * 5). If you’re doing manual pagination with :items from/:items until, keep an offset or current_page + page_size in custom states, slice the list with those values, and display the rank as offset + Current cell’s index (or ((current_page - 1) * page_size) + Current cell’s index).

This gives you a stable sort, proper paging, and a rank that reads 1–5, 6–10, 11–15, etc., without ever using the index to control ordering. If you need a persisted rank to sort by later, store it in a field and update it when ratings change; otherwise, compute the rank on the fly just for display.

correct me if am wrong @boston85719 @georgecollier

Oh thank you for your reply , I am not sorting by Current Cell Index , The current cell index is just a visual cue that displays the ranking after the data has been sorted by dropdown and other fields …. I will try your suggested solution

How can you do the math so that you can take your three variable numbers of cell index, page number, and number of items per page to create a formula to get things to match up as below?

page one is 1,2,3,4,5

page two is 6,7,8,9,10

page three is 11,12,13,14,15

Items per page is 5, so to get on page 2, the cell index of 1 to equal 6 you do items per page + cell index, but when you get to page 3 how do you do cell index of 1 to equal 11, you need 5*2+1, so the 2 part there is the current page number minus 1.

Number of items per page * (current page number -1) + cell index

1 Like

Why is the number of fields a concern that causes you to use pagination and only show the five items per page?

Okay so this is me trying to follow the design mockup , and have less items loading at the same time hence the next and previous buttons …

What would you suggest , say the Solution dB runs to over 1000 records , thank you for your response

For those that may face same issues , I found a solution from a 2018 thread , thanks to @mguerrasio

One way you could do this is do create a hidden repeating group that retrieves your data and then in your visible repeating group that you have set to Fixed number, reference the hidden repeating group as your data source. The use a custom state to control your pagination.

So if you data is coming from a table called “score” you create a hidden repeating group that does a search for records from score. Create a custom state on the page, or the repeating group, called currentDataPageStartIndex as a number type and in an on Page Load workflow, set it to 1.

Then you create your visible repeating group, make its content type be the same as the hidden RG and make the source be - ReapeatingGroup score’s List of scores:items from #pageName’s currentDataPageStartIndex

On your visible repeating group have a text element which has this expression for the text value - pageName’s currentDataPageStartIndex + Current cell’s index - 1

Finally have a Previous 5 button with a workflow that SUBTRACTS 5 from the currentDataPageStartIndex and a Next 5 button that ADDS 5 to the currentDataPageStartIndex

You will need to add conditions to the buttons to disable when you get to the start or end of the record-set. pageName’s currentDataPageStartIndex is 1 and pageName’s currentDataPageStartIndex + 5 > ReapeatingGroup score’s List of scores:count respectively.

here is an example https://helpexamples.bubbleapps.io/version-test/disconnectedrecordset?debug_mode=true

and the editor is you want to see how it is done.

@asiruayomide I’m glad you found a solution that is working for you right now. I would say though that the solution you found from 2018 is outdated, not only because of it’s age (there are still great posts from 2015 early adopters relevant today) but because of the pricing changes that have taken place since 2018. If you are not aware of WU pricing in Bubble, one of it’s major drains on the resource of WUs is returning items from a search. So that 2018 approach of loading 1,000 items in a hidden repeating group, is returning and getting charged for 1,000 items plus the number of characters on each item getting returned. This is a hefty WU consumer due to the fact that for each item returned we are charged 0.015 WUs, so a single page load with 1,000 items in what I call the Legacy approach to data structuring will consume 15 WUs.

Depending on the goals of the application and the expectation for number of users and how often a user may come into find this ranking metric, that 15 WUs might not be too much to consume for just one single feature/function within the application as you do get 175,000 WUs for free each month on starter plan. But if the application is meant to scale and you anticipate high visibility/usage for this single feature of your app, 15 WUs is far too much to consume for one simple feature.

Instead, you can consider checking out my paid Plugin Data Jedi. By using the plugin you can easily in a NoCode environment make use of what I call a Hybrid Data Structure approach that is the hands down cheapest way in Bubble to return small/medium/large lists of data. The approach allows you to return for example, 1,000 objects, for the cost of one single item, meaning only 0.015 WUs. You can see a video demonstration below with a link to the original post I added it to for an illustration of how even the most WU reductive method using the legacy approach doesn’t even come close to comparison to the savings in WUs that Data Jedi and a Hybrid Data Structure approach provide. Not only is it about WU savings, it is about UX as well, since in the video we can see clearly the difference visually between the two approaches and which one would be considered a better User Experience.

1 Like