Should I filter a large Eleventy collection in a data file before pagination, or paginate everything?
0 reputation · 21 Nov 2020, 00:06 UTC
0 reputation · 21 Nov 2020, 00:06 UTC
I'm planning a paginated archive in Eleventy for a collection that could grow to several thousand items. The documented pagination front matter feature (data, size, alias) generates one output page per chunk, so the total file count is roughly ceil(itemCount / size). Assume a current Eleventy 2.x/3.x install; exact option behavior should be confirmed against the installed version.
The unresolved decision is where to bound the dataset. One option is slicing or filtering the collection in a JavaScript data file before pagination sees it, which reduces build time and output. The other is paginating the full collection and hiding unwanted items in the template, which is simpler but still generates every page.
I'm also unsure how stable the generated URLs are: since permalinks typically embed pagination.pageNumber, changing size later seems to shift every page boundary and break published links.
Which approach bounds the build more reliably for large datasets? Does pre-filtering in a data file change anything about how pagination.href.previous/next resolve? And is there a documented way to keep paginated URLs stable when the page size changes?
35275 reputation · 21 Nov 2020, 10:57 UTC
If you want to keep the build time, output size, and page count predictable, filter the collection in a JavaScript data file (or a custom collection) before Eleventy sees it. Paginating the full collection and then hiding items in the template will still generate every page, so the build does not shrink.
pagination front‑matter works on the array you pass to it. The number of output pages is ceil(array.length / size) and Eleventy renders each chunk exactly once.The pagination.href.previous, pagination.href.next, and pagination.pages helpers are calculated from the array that pagination receives. If you filter first, the links point to the pages of the filtered set, exactly as you expect. No special handling is required.
Eleventy’s default permalinks embed pagination.pageNumber. Changing the size value therefore shifts the boundaries of every page and invalidates all previously published URLs. Eleventy does not provide a built‑in way to keep the URLs stable when the page size changes.
size that you treat as permanent and avoid changing it after the site is live.src/data/posts.js could export an array of all posts.
---
pagination:
data: posts
size: 20
alias: posts
---
ceil(filteredCount / 20).
pagination.href.previous and pagination.href.next on the first, middle, and last pages to confirm the links point within the filtered set.
To fine‑tune the recommendation, could you confirm the maximum number of items you anticipate in the archive and whether you plan to change the page size after the site is live?
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.