feat(cache): paginate and cache issue/PR list data #356

New issue

Closed

opened 2026-07-08 08:35:24 +00:00 by fuzzy · 0 comments

fuzzy commented

2026-07-08 08:35:24 +00:00

Owner

What

Add paginated caching for issue and pull request list views (per-repo and global). Fetch all pages on first load, cache them, then only fetch page 1 on subsequent loads and merge.

Why

Currently each view only fetches the first page of issues or PRs. Users with many open items see a short list and lots of blank space. Re-fetching all pages every time is wasteful when data rarely changes between views.

Cache strategy

Condition	Behavior
Cold start (no cache)	Fetch all available pages up to a configurable max (e.g. 500 items), cache per-page keyed by `{context}/issues?page=N` and `{context}/pulls?page=N`
Subsequent loads	Fetch only page 1, merge into cache, render full list from cache
Cache stale	Re-fetch page 1, update cache, render
New issue/PR created	Invalidate cache for that context, trigger cold-start on next view

Data to cache

Cache the full API response per page:

{
  "context": "thwap/steeper",
  "type": "issues",
  "page": 1,
  "total_pages": 5,
  "items": [ ... ],
  "fetched_at": "2026-07-08T08:35:00Z"
}

How

Reuse existing pagination helpers (PageSize=50)
pagesNeeded = min(totalPages, maxPages) where maxPages caps at 10 (500 items)
Store cached page count + fetched_at per context
On page-1 refresh, if item count differs from cache length, trigger full re-fetch

States per view

Loading — spinner during initial multi-page fetch
Progressive — render each page as it arrives
Populated — full list displayed
Cached — instant render from cache, async page-1 refresh in background
Error — show error, fall back to cache if stale data is acceptable

Future

Conditional requests (If-Modified-Since) per page to avoid transferring unchanged pages

## What Add paginated caching for issue and pull request list views (per-repo and global). Fetch all pages on first load, cache them, then only fetch page 1 on subsequent loads and merge. ## Why Currently each view only fetches the first page of issues or PRs. Users with many open items see a short list and lots of blank space. Re-fetching all pages every time is wasteful when data rarely changes between views. ## Cache strategy | Condition | Behavior | |-----------|----------| | **Cold start** (no cache) | Fetch all available pages up to a configurable max (e.g. 500 items), cache per-page keyed by `{context}/issues?page=N` and `{context}/pulls?page=N` | | **Subsequent loads** | Fetch only page 1, merge into cache, render full list from cache | | **Cache stale** | Re-fetch page 1, update cache, render | | **New issue/PR created** | Invalidate cache for that context, trigger cold-start on next view | ## Data to cache Cache the full API response per page: ```json { "context": "thwap/steeper", "type": "issues", "page": 1, "total_pages": 5, "items": [ ... ], "fetched_at": "2026-07-08T08:35:00Z" } ``` ## How - Reuse existing pagination helpers (PageSize=50) - `pagesNeeded = min(totalPages, maxPages)` where `maxPages` caps at 10 (500 items) - Store cached page count + `fetched_at` per context - On page-1 refresh, if item count differs from cache length, trigger full re-fetch ## States per view - **Loading** — spinner during initial multi-page fetch - **Progressive** — render each page as it arrives - **Populated** — full list displayed - **Cached** — instant render from cache, async page-1 refresh in background - **Error** — show error, fall back to cache if stale data is acceptable ## Future - Conditional requests (`If-Modified-Since`) per page to avoid transferring unchanged pages

fuzzy added the

Kind/Enhancement

Priority

High

labels

2026-07-08 08:35:24 +00:00

fuzzy self-assigned this

2026-07-08 08:35:24 +00:00

fuzzy changed title from ~~adding issue and pull request data to cache~~ to feat(cache): paginate and cache issue/PR list data

2026-07-08 08:35:49 +00:00