Problem
src/components/ui/StatCard.tsx is used across all three dashboards to show headline figures (per the README: sponsor budget remaining, contributor earnings, maintainer pipeline counts). Numbers presented in large, prominent stat cards on a financial dashboard are exactly the kind of content that gets financially significant when wrong — but there's no evidence of any dedicated handling for the specific numeric edge cases that will occur at real scale: what does StatCard render for a brand-new sponsor with $0 funded (does 0 read as "no data yet" ambiguously, or clearly as a real zero)? What happens with a very large number (a highly successful platform's aggregate figures) — does formatting degrade (e.g. Intl.NumberFormat-based abbreviation like "1.2M" needs a threshold decision, and un-abbreviated large numbers can overflow fixed-width card layouts)? What renders while the underlying Server Component fetch is pending if StatCard is ever used in a streamed/suspended context (relevant given the loading-state issue elsewhere in this batch) — a flash of 0 or undefined that looks like a real, alarming figure (a sponsor briefly seeing "$0 budget remaining" before the real figure streams in is a bad, trust-eroding experience distinct from a generic skeleton)?
Why this is hard
- Requires reading
StatCard.tsx's actual props/rendering logic to determine current handling (if any) of zero, loading/undefined, and large-number cases, since none of this is documented and stat cards are exactly the kind of component that gets built for the happy-path demo data in mock-data.ts (which likely has "nice," round, medium-sized numbers) and never stress-tested against real edge values.
- The "zero vs. loading vs. error" ambiguity is a real design problem, not just a coding task: these three states need visually distinct treatment (e.g. a skeleton shimmer for loading, a deliberate "0" or "—"/"No activity yet" for genuine zero, and a distinct error/unavailable indicator for fetch failure) and
StatCard's prop interface likely needs to change to accept an explicit state rather than just a number that's ambiguous across all three cases — this is an interface design decision with call-site ripple effects across all three dashboards.
- Large-number formatting needs a genuine threshold/abbreviation policy (when does "$1,234,567" become "$1.2M," and should hovering/focusing reveal the exact figure for a financial figure where abbreviation-induced ambiguity is worse than in a casual social-media-follower-count context — arguably a sponsor needs to see exact budget figures, not abbreviated ones, which pushes toward a different solution: responsive font sizing or truncation with an accessible full-value tooltip, rather than abbreviation) — this requires a considered domain-appropriate decision, not a generic "add abbreviation" pattern copied from elsewhere.
- Must verify the fix works correctly composed with whatever comes out of the loading/Suspense-boundary work and the decimal-precision work elsewhere in this batch, since
StatCard sits at the intersection of both.
Scope
- Redesign
StatCard's interface to explicitly and distinctly represent loading, zero/empty, error, and populated-value states rather than inferring them ambiguously from a bare number.
- Decide and implement a domain-appropriate large-number display policy for financial figures (favoring exact-value accessibility over lossy abbreviation, e.g. responsive sizing/truncation with an accessible full-value affordance) rather than a generic abbreviation scheme.
- Update all dashboard call sites to pass the new explicit state rather than a bare number.
- Add tests/stories covering zero, loading, error, typical, and very-large-value cases for visual/regression verification.
Acceptance criteria
- Loading, zero, error, and populated states are visually and semantically distinct in
StatCard, verified by rendering all four side by side.
- A very large financial figure never overflows or gets silently truncated without an accessible way to see the exact value.
- No dashboard ever flashes a
0 or blank stat card that could be mistaken for a real zero value during data loading.
Problem
src/components/ui/StatCard.tsxis used across all three dashboards to show headline figures (per the README: sponsor budget remaining, contributor earnings, maintainer pipeline counts). Numbers presented in large, prominent stat cards on a financial dashboard are exactly the kind of content that gets financially significant when wrong — but there's no evidence of any dedicated handling for the specific numeric edge cases that will occur at real scale: what doesStatCardrender for a brand-new sponsor with$0funded (does0read as "no data yet" ambiguously, or clearly as a real zero)? What happens with a very large number (a highly successful platform's aggregate figures) — does formatting degrade (e.g.Intl.NumberFormat-based abbreviation like "1.2M" needs a threshold decision, and un-abbreviated large numbers can overflow fixed-width card layouts)? What renders while the underlying Server Component fetch is pending ifStatCardis ever used in a streamed/suspended context (relevant given the loading-state issue elsewhere in this batch) — a flash of0orundefinedthat looks like a real, alarming figure (a sponsor briefly seeing "$0 budget remaining" before the real figure streams in is a bad, trust-eroding experience distinct from a generic skeleton)?Why this is hard
StatCard.tsx's actual props/rendering logic to determine current handling (if any) of zero, loading/undefined, and large-number cases, since none of this is documented and stat cards are exactly the kind of component that gets built for the happy-path demo data inmock-data.ts(which likely has "nice," round, medium-sized numbers) and never stress-tested against real edge values.StatCard's prop interface likely needs to change to accept an explicit state rather than just a number that's ambiguous across all three cases — this is an interface design decision with call-site ripple effects across all three dashboards.StatCardsits at the intersection of both.Scope
StatCard's interface to explicitly and distinctly represent loading, zero/empty, error, and populated-value states rather than inferring them ambiguously from a bare number.Acceptance criteria
StatCard, verified by rendering all four side by side.0or blank stat card that could be mistaken for a real zero value during data loading.