[#371] Cursor-based Load more pagination

[realproject7]

Summary

• Switches all three "Load more" lists from re-fetching everything with increasing limit to fetching only the next page at the correct offset
• Accumulated rows stored in refs, appended as new pages arrive
• Affected: reader donation history, reader trading history, writer donation history
• Button shows "Loading..." and is disabled during fetch

Fixes #371

Test plan

• Reader dashboard: click Load more on donations — verify new rows append without re-fetching earlier ones
• Reader dashboard: click Load more on trading history — same behavior
• Writer dashboard: click Load more on donation history — same behavior
• Switch wallets — verify lists reset correctly

🤖 Generated with Claude Code

[project7-interns]

LGTM. Consistent cursor-based pattern across all three lists. Offset-based range() queries fetch only the next page. Ref-based accumulation avoids re-render loops and the idempotent guards (length === offset check) prevent duplicate appends. Address-change reset logic is correct. Loading state with disabled button is a nice UX touch.

[project7-interns]

Verdict: REQUEST CHANGES

Summary

The reader-side pagination changes are aligned with issue #371, but the writer donation history introduces a state-reset regression. Accumulated rows are kept in a ref without being cleared when the selected storylineId changes, so the list can show stale rows from the previously opened storyline.

Findings

• [medium] Writer donation history does not reset accumulated pages when switching storylines.
  • File: src/app/dashboard/writer/page.tsx:191
  • Suggestion: Clear the accumulated ref and reset the offset whenever storylineId changes, the same way the reader dashboard resets on address change.
• [info] lint-and-typecheck was still pending at review time.
  • File: src/app/dashboard/writer/page.tsx:191
  • Suggestion: Wait for required checks before merging.

Decision

Request changes. The new pagination approach is fine, but the writer dashboard needs a storyline-change reset to avoid stale donation history data.

[project7-interns]

Verdict: APPROVE

Summary

The storyline-change regression in writer donation history is fixed. The PR now delivers the intended offset-based pagination for all three lists without carrying stale writer data across storyline switches.

Findings

• [info] lint-and-typecheck was still pending again at review time.
  • File: src/app/dashboard/writer/page.tsx:191
  • Suggestion: Wait for required checks before merging.

Decision

Approve. The earlier reset bug is addressed and the pagination changes now match issue #371.

[project7-interns]

Re-approved after fix. WriterDonationHistory now correctly resets offset and accumulated ref on storylineId change via the same prevStorylineId pattern used for address changes in the other components. Stale data issue is resolved.

[project7-interns]

Re-approved after useInfiniteQuery refactor. Much cleaner — react-query handles page accumulation natively, no refs or manual reset needed. queryKey includes the entity ID so cache auto-invalidates on address/storyline change. getNextPageParam offset logic is correct. Consistent pattern across all three lists.

[project7-interns]

Verdict: APPROVE

Summary

The latest revision replaces the manual ref accumulation with useInfiniteQuery, which keeps the cursor-based pagination behavior from issue #371 while resolving the React Compiler / react-hooks/refs CI failure. The earlier writer-storyline reset concern is also no longer applicable because page accumulation is now keyed by the query key.

Findings

• [info] lint-and-typecheck was still pending again at review time.
  • File: src/app/dashboard/reader/page.tsx:1
  • Suggestion: Wait for required checks before merging.

Decision

Approve. The updated implementation is scoped correctly and the CI-motivated refactor still satisfies the pagination requirement across all three lists.