[FEAT] Add Stale-While-Revalidate (SWR) Local Storage Cache Layer for Offline Dashboard Resiliency

[dhruvil-1207]

Problem Statement

When developers work on a spotty local network, travel, or encounter temporary GitHub API rate-limiting blocks, the core dashboard widgets can freeze, display heavy loading spinners, or drop into empty un-hydrated states. There is currently no persistent client-side state backup to display immediate fallback metric snapshots.

Proposed Solution

Implement a lightweight client-side data resiliency layer using a Stale-While-Revalidate (SWR) model:

1. Local Snapshot Storage: Intercept successful incoming API dashboard metrics payloads (commit streaks, PR tracking analytics, goals) and store them as a stringified JSON snapshot in localStorage with a timestamp.
2. Instant Hydration & Silent Sync: On initial dashboard load, immediately populate UI cards with the saved localStorage snapshot if available. Concurrently dispatch a background fetch request to sync live data and silently update the layout state once resolved.

Feature Area

Dashboard

Alternatives Considered

• Forcing strict loading states: Keeping the layout blocked behind a continuous loading spinner panel until a live network bridge resolves, which hurts UX speed and breaks accessibility during offline sessions.

Acceptance Criteria

• Dashboard displays the last cached metrics instantly on hard refresh without a prolonged blank loading state.
• Toggling the browser network connection to "Offline" retains existing metric values instead of crashing widget components.
• Background network requests silently overwrite the stale local storage baseline metrics once internet connectivity re-establishes.
• Proper handling ensures zero runtime crashes if localStorage is completely empty or disabled by browser flags.

Additional Context

This is an isolated client-side enhancement focused purely on developer experience (DX) and frontend speed optimization. I am a GSSoC '26 contributor and am ready to build this caching wrapper cleanly. Could you please review and assign this issue to me?

[github-actions]

Thanks for opening your first issue on DevTrack! 🎉

A maintainer will take a look shortly. In the meantime:

• Check the Contributing guide if you are planning to work on this
• Browse Discussions for Q&A and ideas
• Look for good first issue if you want somewhere to start

If you find DevTrack useful, a ⭐ star on the repo is always appreciated — it helps the project reach more developers!

[dhruvil-1207]

Hey @Priyanshu-byte-coder,
I would like to work on this issue for GSSoC'26
Please assign this to me

[github-actions]

Assigned to @dhruvil-1207! You have 7 days to open a PR. No PR after 7 days = auto-unassigned so others can pick it up. Good luck!

[dhruvil-1207]

Hey @Priyanshu-byte-coder! I've opened a PR #2883 for this issue. I implemented the SWR caching layer from scratch for the PRMetrics, StreakTracker, and GoalTracker widgets.

To ensure high quality, I made sure to include typeof window !== 'undefined' checks so it's fully safe for Next.js SSR, and added try/catch blocks around all localStorage parsing so the app won't ever crash for users who have strict privacy blockers or corrupted cache.

Tested it locally by simulating 'Offline' mode and it gracefully falls back to the cache perfectly. Let me know if you'd like any changes before assigning the GSSoC labels!