Repository source: docs/plans/archive/forte_activity_pagination_step1_solution_assessment.md
Forte Activity Pagination — Step 1: Solution Assessment
Problem
The Activity feed silently caps every view at 100 items (ACTIVITY_ITEM_LIMIT, inherited verbatim from classic), which looks odd and hides older activity, but loading thousands of items at once wouldn't be usable either.
Option A: Raise the limit
Bump ACTIVITY_ITEM_LIMIT to a larger fixed number (e.g. 500).
Pros: one-line change, no new UI or query logic.
Cons: doesn't fix the underlying problem, just moves the wall further out; will look arbitrary again as the site grows; explicitly rejected by the "thousands of items wouldn't be great either" constraint.
Option B: "Load more" pagination
Add a "Load more" control at the bottom of the item list; each click fetches the next page (offset/cursor-based) for the current filter and appends rows, reusing fetchActivity()'s existing per-view query with an added offset.
Pros: small, bounded initial load; user can page as deep as they want, so "the whole picture" is reachable without a giant single payload; fits the existing list-pane/row pattern (append, don't replace); the per-row view-membership flags this feed's Stage 1 already computes extend naturally to additional pages.
Cons: needs an offset/cursor param threaded through the 5 per-view
fetchActivity()calls (from the prior cycle's "fetch each view separately" fix) consistently, so paging state doesn't drift between filters.
Option C: Time-window browsing (e.g. by day/week)
Replace the flat item cap with date-bounded windows the user steps through (today/this week/older), each independently queried.
Pros: gives real temporal orientation rather than an arbitrary count cutoff.
Cons: meaningfully larger scope - new date-bucketing query logic per view, new UI for window selection, a bigger departure from classic's own (uncapped-by-date) behavior than this problem calls for.
Recommendation
Option B. It directly answers both halves of the problem - the feed stops silently hiding data, and nothing forces a thousands-of-rows payload - with the smallest new surface area, and it composes cleanly with the per-view fetch/flag logic already in place.