Cursor based pagination with Static generation (directly fetching static props json) #13628
janus-reith
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I found myself still using offset-based page navigation instead of working with a cursor and doing endless scrolling in many cases, mainly because this way I could create static sites for each page, thereby allowing an user to skip to a page 5, without having to execute queries for that clientside.
Instead I could also use a cursor in the url, and then just show next/prev buttons, but that seems not that inituitive.
What I'm considering now is, how an endless scrolling approach could work out with static generation. What I have in mind is this:
Viewer A is scrolling a list of blog posts, going further back in time - Each 20 posts, a new fallback static page is generated, that user just recieves the json from static props and the revelant entries from there are appended client side.
Viewer B might click somewhere to be taken directly to all posts from January 2018, that could be a similar starting cursor and therefore, no additional db query is executed, and no new SSR render, as that page already was created when Viewer A scrolled.
One drawback I see with this is, that each time a new post is added to the first page, things would get out of order, but I believe some more sophisticated approach could reuse the existing sections starting at certain ids, as opposing to typical pagination there is no strict requirement to fetch an exact amount of posts each time where possible.
However, even without such an approach the assumption would be, that at a certain scale that is quickly reached, creating these static pages would still be more performant and result in less database calls than each client fetching an api directly.
(I say at a certain scale, because there could be rare circumstances with a really low number of users but frequent new posts where creating a static page that accompanies each request for new entries would be more overhead than that few users fetching an api for posts directly)
Technically it should work out to just fetch the json, similar to how nextjs links do for client side navigation, but I wonder what the most streamlined approach is and where I need to be careful as things might break in future releases.
For example a path I might fetch on the client then during scrolling could look like this in dev mode:
/_next/data/development/some/route/mycursorId.json
while in production it would be:
_next/data/SOMEBUILDID/some/route/mycursorId.json
Is could probably just substitute that easily, but fell like there could be some generic approach.
Beta Was this translation helpful? Give feedback.
All reactions