My use case is for a UI sorted table. It’s sent via graphql but the transport doesn’t really matter here. It need to be sorted, then paged, then hydrated (pull). As with most UI tables, it will need runtime provided where conditions. I believe this is a pretty common UI requirement. It would be the same if the UI was infinite scroll vs classic paging.
Today I do this with:
- a sorted datalog query (sort field and id only)
- drop n, take n
- run N pulls for the page of records (could alternatively be a second query)
The core constraint is the sorted first step. I’m hoping there’s now a better way to do this.
My current solution could become a problem if the dataset becomes large because it will effectively be a full scan to find/sort the results.
Thanks for the feedback