fix(ui): request answers page by page instead of 999 at once - #1573
Open
culfin wants to merge 1 commit into
Open
fix(ui): request answers page by page instead of 999 at once#1573culfin wants to merge 1 commit into
culfin wants to merge 1 commit into
Conversation
The question page already has everything it needs to paginate: the page
number comes from the URL, a useEffect reloads when it changes, and a
Pagination control is rendered. Only the request ignores all of it and
asks for 999 answers in one go.
Two consequences:
Answers past the 999th are unreachable. The list never contains them,
and because the count shown is the length of that list, the heading
claims the question has 999 answers. A forum I maintain has two threads
above that limit, with 13368 and 10110 answers; roughly 22000 posts were
inaccessible through the UI.
Long questions are slow. Measured on a question with 999 answers, the
browser needs 19s before the first answer is visible, against 0.2s for
an ordinary one — it has to parse and hydrate a thousand posts to show
fifteen.
Changes:
- request `page` from the URL and ANSWER_PAGE_SIZE per page
- take the total from `res.count` rather than the length of the
current page, so the heading and the page count stay correct
- name the page size once instead of repeating 15 in three places
One behavioural note: the list is filtered client-side to hide deleted
answers that only their author and admins may see. With every answer
loaded, counting the filtered list gave an exact total. Now the total
comes from the server and can be off by the number of deleted answers
on the current page. Filtering these server-side would remove the
discrepancy, but that seemed out of scope here.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The question page already has everything it needs to paginate: the page number comes from the URL, a
useEffectreloads when it changes, and aPaginationcontrol is rendered. Only the request ignores all of it:Answers past the 999th are unreachable. The list never contains them, and since the displayed count is the length of that list, the heading claims the question has exactly 999 answers. In the forum I maintain two threads are above that limit — 13368 and 10110 answers — so roughly 22000 posts could not be reached through the UI at all.
Long questions are slow. Measured on a question with 999 answers:
The browser parses and hydrates a thousand posts in order to show fifteen.
Proposed Changes
pagefrom the URL andANSWER_PAGE_SIZEanswers per pageres.countinstead of the length of the current page, so the heading and the page count stay correct15in three placesOne behavioural note
The list is filtered client-side to hide deleted answers that only their author and admins may see. With every answer loaded, counting the filtered list happened to give an exact total. Now the total comes from the server and can be off by the number of deleted answers on the current page. Filtering those server-side would remove the discrepancy entirely, but that looked out of scope for this fix.
Verified with
prettier --checkagainst the projects config.