feat(frontend): surface silent failures + empty/disabled-state UX#204
Conversation
Staff-facing observability + clearer states (no happy-path change): - Analytics: distinguish a failed section (with retry) from genuine "no data" instead of swallowing fetch errors with .catch(()=>null) - AdStudio: empty-state for no scheduled posts / no voices, and a reason when GenAI generation is disabled by readiness - ErrorBoundary: best-effort fire-and-forget crash report to /api/analytics (cannot throw), fallback UI unchanged Customer lead forms — SOFT, non-blocking only (never gate a valid submission): - Contact: soft email-format hint; phone remains the only hard requirement - Appointments: explain disabled dates + soft email hint Frontend build: vite build clean. CRM unchanged (feedback already present). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b9a7ad55be
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const failed = { | ||
| leads: !leadsResp?.ok, | ||
| documents: !docsResp?.ok, | ||
| inventory: !invResp?.ok, | ||
| chat: !chatResp?.ok, | ||
| events: !eventsResp?.ok, |
There was a problem hiding this comment.
Treat analytics error payloads as failed sections
When an analytics endpoint hits its exception handler, the backend returns {"error": ...} with the default HTTP 200 (for example main.py's analytics routes), so resp.ok is still true here. In that scenario this code sets the stats state to the error object and leaves sectionErrors false, so the new retry/error UI still renders as zeros or empty data instead of surfacing the failed section. Parse the JSON for an error/expected shape, or have the server return a non-2xx status.
Useful? React with 👍 / 👎.
| aria-describedby={showEmailHint ? 'contact-email-hint' : undefined} | ||
| /> | ||
| {showEmailHint && ( | ||
| <p id="contact-email-hint" className="text-xs text-amber-700 mt-1">This email looks incomplete. You can still send without it.</p> |
There was a problem hiding this comment.
Make optional email hints actually non-blocking
This hint appears for an invalid optional email, but the same input remains a native type="email", so browsers block the form before handleSubmit runs when a visitor leaves a typo like john@ in place. That means a lead with a valid phone can still be dropped despite the new soft-warning copy; the same pattern was added to the appointment email field too. Use noValidate, a text input, or strip/ignore invalid optional email values if these hints are meant to be non-blocking.
Useful? React with 👍 / 👎.
Wave 2 of the "finish & perfect" campaign — frontend observability + empty/disabled-state UX. All additive; no happy-path changes.
vite buildclean.Staff-facing
.catch(()=>null)making a failed fetch look like "no data". Full-page error only when all sections fail./api/analytics; fallback UI unchanged.Customer lead forms — SOFT, non-blocking only
Each change was adversarially reviewed, including an explicit "could this ever block a valid submission?" check on the lead forms (answer: no). CRM was left unchanged — the error feedback it was scoped to add already exists.
🤖 Generated with Claude Code