Table or grid pagination

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


@chrisbarsis33 I think you could get a similar result with some clever filtering.

The simple version has two controls: records_start and records_end

Add in a Dynamic RowID as described over here: Consecutive Row Numbers?

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.

1 Like

Interesting solution.

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?

(Use case: dashboards displayed on TVs)

@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.

Thanks for your consideration.

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?

Thanks for your help!

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.

I reiterate what I stated earlier: Lack of pagination is a shortcoming that hampers my ability to work with tables.

The welcome page states: Coda is a new canvas that blends tables and text together — a unified workspace your team will never outgrow.

To be blunt, I am outgrowing Coda. It’s simply hard to work efficiently with more than a couple of records.

Having this ability would be a KILLER feature!

1 Like

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.

In the meanwhile, you can also achieve much better results when working with a big table by using a canvas control ( or simply by switching to a “Detail Layout”.

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.


1 Like

For those watching this thread, we just made some announcements related to performance: