Provide the option to show a set number of records.
So if there are 100 records, provide the option to view X at a time.
Example #1: Show 10 records at a time
100 records / 10 per set = 10 pages
Page 1 of 10: records 1-10
Page 2 of 10: records 11-20
Example #2: Show 15 records at a time
100 records / 15 per set = 7 pages (6 pages of 15, page 7 would have 10)
Page 1 of 10: records 1-15
Page 2 of 10: records 16-30
Then! Filter the table as such: d_rowID >= records_start AND d_rowID <= records_end
If you are looking for a specifically paged view, you should implement this with named fields page_number and records_per_page (type =10 in the canvas and select the dropdown arrow).
You still need the d_rowID as above.
Then, filter the table with: d_rowID > (page_number-1)*records_per_page AND d_rowID <= (page_number)*records_per_page
This gives us rowID between 11 and 20 (inclusive) if we have 10 records per page and select page 2.
I have a situation where I need to paginate a view of a master table. E.g. show me the first 10 projects whose status is “Active”, sorted by due date.
And then in a separate view, show me projects 10-20 whose status is “Active”, sorted by due date.
So the challenge is I need to calculate rank after filtering and sorting have been applied, and then truncate. Thoughts on how to achieve this?
@chris_homburger I appreciate the suggestion for table or grid pagination.
After spending about an hour trying to configure my table, I decided to just move on from this. It’s kind of a cumbersome workaround, wish this just worked out of the box.
For what it’s worth, I work with Sencha as a front end library when doing front end web development. When you start dealing with larger data sets, it’s simply easier to work with a subset of the table, instead of scrolling (endlessly) to locate your record.
My $.02 - this would be a killer feature, if Coda decided to implement it. If you really want to make tables easy to work with, I would put this feature at the top of the list.
Good use case—I think the above solution can be implemented if you replace the dynamic row ID with the rank you need. You can use the rank() formula to achieve this pretty easily:
Make a column “rank” =rank(thisRow.date_due, thisTable.date_due, true). This will rank the due dates in ascending order (first due at the top). In the above solution, replace d_rowID with your new rank column.
If you only want to display active projects, you should add a conditional: rank = if(status="Active",rank(date_due, thisTable.filter(status="Active").date_due), "" )
This will give you null values in projects that are not active, and the rank within the subset of active projects in those that do.
Does that help? Happy to share an example doc with you as well.
Sorry this didn’t work out for you—if you want to share the document you’re trying to work in, or a scrubbed example of it, I’m happy to help you out directly.
Oh I see yeah - so manually re-create the same kind of filtering/sorting within the rank formula. A bit clumsy, but good workaround! I’ll give this a try.
Ok tried it and it’s quite close, but I’m getting lots of ties (multiple entries with same rank).
I could break the ties using additional sorting, e.g. after sorting by date due, sort by time due and then alphabetically by project name. I’ve reviewed the documentation for rank() but it’s not apparent to me how I could chain multiple instances of it to refine the sort. Is that possible?
Any update from Coda on this? It seems crazy to not have pagination - we’re looking at implementing tables with many hundreds of rows in a queue system. I don’t want to have to concoct some sort of filtering pattern just to page through results.
Hey everyone, thanks for the request around being able to have pagination on a large table. We’ve added to our list and are actively discussing how to prioritize this against other efforts.
For what it’s worth, we are actively working on improving the experience of working with a large tables so that it is much less painful even without pagination.
It would be super useful if some of you can share specific docs where pagination would still come in handy so we can prioritize accordingly. Would love your feedback in any form like a message in intercom, sharing the actual doc, a screen recording or a video call.
@Angad I use Coda for professional as well as personal use cases. One of my personal use case is to catalog my entire Vinyl collection. Essentially the database of all Albums, Tracks and all of their metadata (E.g. Performing Artist, Composer, Lyricist, Genre, album art and so on). I then create separate pages for my fav music composer/artist. I want to list all of their albums, tracks. This can go in 100s. Not having pagination makes the page endlessly scrolling. Having Pagination will be valuable in almost any table that has hundreds of records.
Would like to understand the reason for “not” having it.
Has there been any movement on pagination? Especially with the new user-side filters, it’s hard to construct a useable workaround (Order of Operations needs to be Filters->User Filter Bar->Pagination Logic) which is not currently possible as implemented.
Especially for - for instance - dashboards that surface the most important items on large lists, it’s difficult not to run things off the end of a page.