The new owners page has too many containers #137
Labels
No labels
actions
bug
cli
duplicate
enhancement
fork
forum
git storage
help wanted
insights
invalid
issues
moderation
oidc
ownership transfer
packages
pr/merge protection rules
projects
pull requests
question
releases
sponsorships
tags
webhooks
wiki
wontfix
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
crueber/walhub#137
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Redesign this so it isn't so busy.
Make sure that it shows the number of stars a repo has. That should be default across the application, anywhere that a repo is shown. Like: walhub (3 ⭐️) or something like that
Fix ready for review: #141 (branch fix/issue-137) — flattens the owners page to a divider stack (intro/caps/order/overflow from #117 kept) and adds (N ⭐) counts to every repo row on / and /:owner via the shared social:{o}/{r} 30 s cache key (non-blocking placeholder, 500-GET worst case bounded by the caps). No backend change, no new deps; 313/313 unit tests green, browser-verified dark+light with zero console errors.
PR #141 review (branch fix/issue-137, commit
4cb3e1b+ review fixupec7ca43):CALMNESS — PASS. Owner sections drop .card for a divide-y divider stack (Owners.jsx:103), intro card kept (:86), heading quieter text-sm (:26) with the repo count folded inline (:30-36). Caps (MAX_OWNERS/MAX_REPOS_PER_OWNER), +N-more overflow links, newest-first order, and the 'showing newest 50' line all intact. Matches the BEFORE screenshot's complaint (nested cards).
STAR COUNTS — PASS. Every repo row on / (Owners.jsx:55) and /:owner (Repos.jsx:42) renders ; no other repo-listing UI exists (Org.jsx has no listing; starred lists are SDK-only), so coverage is complete. Placeholder is muted (...) text-xs with aria-hidden (StarCount.jsx:31) — same size class as the final count, so layout shift is negligible. Zero counts render as (0 ⭐), bad data hides to the placeholder (stars.js:18-23). No new deps (package.json untouched); dark+light via .muted/emerald + divide-zinc-200/dark:divide-zinc-800; keyboard unchanged (plain anchors).
PERF (law 6) — ACCEPTABLE AS-IS, explicitly: bounded + cached + non-blocking, no lazy-load required. Single-flight verified in lib/data.js:117-122 (shared entry per social:{o}/{r} key, concurrent mounts join the in-flight promise). Non-blocking verified: the link renders as a sibling, counts resolve behind the Show fallback — first paint never waits. Repeat visits within the 30 s TTL cost zero GETs (matches the pre-existing 08 §6 social:{o}/{r} row and collab.js TTL). 500-cold worst case (50×10 caps) is tiny JSON GETs against the existing SWR+ETag endpoint, failures go to the tray (TRAY_MAX 6, deduped), progress bar tracks via trackPending. No backend change needed — repo.social.get() (sdk/social.js:28) and GET …/social already exist.
TWO SMALL DOC FIXES PUSHED (
ec7ca43, re-tested): (1) StarCount.jsx header claimed the repo-chrome star toggle shares these cache entries — it does not (Repo.jsx:306 calls social.get() directly, outside useData); wording corrected. (2) 12_web_ui.md 'repeat visits cost zero GETs' now notes the 400-entry LRU cap: a fully-maxed 500-row cold load evicts oldest entries, so the absolute worst case refetches some. Correctness unaffected.VERIFY: node --test web/test/unit/*.test.js → 313/313 pass (incl. 4 new stars tests); vite build clean (119 modules). No browser per instructions (node tests + code reasoning only). Main worktree untouched (read-only); scratch worktree removed after push.
RECOMMENDATION: ready to merge.
Fixed by PR #141 incl. review doc fixes (calm dividers, star counts with bounded cached fetching; 313/313 node tests), merged. Closing.