fix(ui): use LoadingState/ErrorState in NotificationReadinessCard#7047
Conversation
The card collapsed loading and error into one plain-text branch ("Loading notification model..." vs "Notification model unavailable."), discarding the errorKind/error useApiResource already exposes and giving no retry action -- unlike every other useApiResource consumer in this app, which already uses the shared LoadingState/ErrorState from state-views.tsx. Replaced the collapsed branch with those two components, wiring through the real error message, errorKind, and a retry action. The success-path rendering is unchanged.
|
Superagent didn't find any vulnerabilities or security issues in this PR. |
|
Tip ✅ LoopOver review result - approve/merge recommendedReview updated: 2026-07-17 19:32:51 UTC
Review summary Nits — 4 non-blocking
Decision drivers
Context & advisory signals — never blocks the verdict
Linked issue satisfactionAddressed Review context
Contributor next steps
Signal definitions
🧪 Chat with LoopOverAsk LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.
Full command reference: https://loopover.ai/docs/loopover-commands 🧪 Experimental — new and may change. Visual preview
Click any thumbnail to open the full-size screenshot. Before = production · After = this PR's preview deploy. 🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed 💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →. Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.
|
Summary
NotificationReadinessCard(apps/loopover-ui/src/components/site/notification-readiness-card.tsx) collapsed its loading and error states into one plain-text branch ("Loading notification model..."vs"Notification model unavailable."), discarding theerror/errorKindfieldsuseApiResourcealready exposes and giving no retry action -- a real fetch failure and "still loading" rendered identical generic copy, unlike every otheruseApiResourceconsumer in this app.LoadingState/ErrorStatefromstate-views.tsx, wiring through the real error message,errorKind, and a retry action (onRetry={model.reload}). The success-path rendering (theprivacyGuardslist, opt-in controls) is unchanged.notification-readiness-card.test.tsxcovering all three render paths: loading, error (with the real message + working retry), the network-specific error copy, and success.Scope
type(scope): short summaryConventional Commit format.CONTRIBUTING.mdand does not reintroduce GitHub Pages, VitePress,site/, orCNAME.Closes #6985
Validation
git diff --checknpm run actionlint(no workflow changes in this PR)npm run typecheck(vianpm run ui:typecheck, the UI-scoped equivalent)npm run test:coverage(backend-only; this PR only touchesapps/loopover-ui, which is outside the Codecov patch gate percodecov.yml'signore: apps/**)npm run test:workers(not applicable to this UI-only change)npm run build:mcp(not applicable to this UI-only change)npm run test:mcp-pack(not applicable to this UI-only change)npm run ui:openapi:check(no API/schema changes in this PR)npm run ui:lintnpm run ui:typechecknpm run ui:buildnpm audit --audit-level=moderate(no dependency changes in this PR)If any required check was skipped, explain why:
apps/loopover-ui/src/components/site/notification-readiness-card.tsx(plus its new test file). The backend-only checks above have no surface to exercise for a change scoped entirely to one UI component's loading/error branches;npm run ui:lint,npm run ui:typecheck, andnpm run ui:buildall pass locally, and the new test suite (4 tests) covers the loading, error (both generic and network-specific copy), and success render paths, including the retry action.Safety
UI Evidencesection below with JPG/JPEG or PNG screenshots arranged as organized, captioned, clickable thumbnails. SVG screenshots are not used as review evidence. Review-only screenshots or recordings are not committed to the repository.UI Evidence
Notes