admin d71b67a297 feat(ui): global react-query error handler + plan-status a11y (Sprint 4 F7+F6)
F7: surface every failed query/mutation as a toast via react-query
QueryCache/MutationCache onError, with a single error normalizer that
extracts FastAPI's response.data.detail (string or Pydantic 422 array).

- lib/toast.tsx: new extractErrorMessage(err, fallback) and
  showApiError(err, fallback). Reads response.data.detail when present
  (string or [{loc, msg, type}, ...] array), then err.message, then
  the fallback. No more '[object Object]' or raw stack traces.

- App.tsx: QueryClient is now created with QueryCache and
  MutationCache onError handlers wired to showApiError. Added
  defaultOptions.queries: { retry: 1, refetchOnWindowFocus: false }
  so background refetch failures are no longer silent (the audit's
  H9 finding).

- Dashboard.tsx: removed 6 local try/catch toasts (move/approve/deny/
  delete/generate) since the global handler now covers them. Kept
  VoteEmailButton.handleSend and handleDelete's undo-callback with
  showApiError(err, 'Failed to ...') for action-specific fallback
  strings — those are user-initiated recovery paths where a contextual
  default is more useful than the bare FastAPI detail.

- Pantry.tsx: removed 3 local onError handlers (addMutation,
  removeMutation, handleAdd's createIngredient path) and
  handleRemove's outer catch. Kept 3 pre-flight client-side checks
  (missing ingredient link, empty name, unresolved ingredient) that
  never reach the network. handleRemove's undo callback now uses
  showApiError for the restore failure.

- MealDetail.tsx: removed submitMutation.onError. The local
  'Failed to save feedback. Please try again.' string is replaced
  by the actual FastAPI detail (e.g. 'Feedback for this meal already
  exists' or the Pydantic 422 msg).

Net result: 10 backend-error try/catch blocks deleted, error messages
are now identical to what the backend actually says, and any future
mutation that forgets to add a local onError still gets surfaced.

F6: Dashboard plan-status Badge (variant driven by status: draft /
awaiting_approval / approved / rejected) now passes an explicit
aria-label='Plan status: <text>' so a screen reader announces both
the category and the value instead of just the colour-encoded text.
This matches the pattern already used for the per-item approval
status Badge in Dashboard.tsx (added in Sprint 3) and completes the
audit §Sprint 3 a11y sweep for that page.

build: tsc 0 errors, vite 0 errors. 5 files, +72/-19.
2026-06-03 19:33:54 -07:00

Meal Planner

Self-hosted meal planning system that integrates with Lucky California grocery store, sends weekly meal proposals via email to family members, generates shopping lists, and learns from feedback.

Background

This project was born out of frustration with meal kit services (Blue Apron → EveryPlate → HungryRoot → Sunbasket) that:

  • Escalate costs to 3x ingredient markup
  • Fall into repetitive meal rhythms
  • Force users to log into apps to manage selections
  • Don't integrate with home pantry items

Features

  • Grocery Integration: Scrapes Lucky California weekly ads and sales
  • Family Approval Workflow: Email proposals with approve/deny; one denial swaps the meal
  • Shopping List Generation: Weekly list grouped by store aisles, highlighting sales, with interactive checkboxes to track purchased items
  • Pantry Integration: Specify home items to incorporate into suggestions
  • Web UI: Modern interface for the whole family
  • Learning: Feedback-based meal recommendations, with weekly auto-discovery of new recipes from external APIs when family preferences are signaled
  • Recipe Images: Scraped from public recipe sites, AI fallback available
  • Unit Conversion: Converts recipe quantities (cups, tbsp, lb) to grocery units for accurate cost estimates

Architecture

  • Backend: Python/FastAPI
  • Database: PostgreSQL
  • Frontend: React + Tailwind CSS
  • Email: SendGrid
  • Hosting: Docker Compose with nginx reverse proxy

Documentation

Quick Start

# Clone and start
docker-compose up -d

# View logs
docker-compose logs -f

# Stop
docker-compose down

Family Profile

Household: 2 adults, 2 children

  • One adult likes mushrooms, one child OK with them
  • Three family members do NOT like mushrooms
  • No allergies
  • Calorie, budget, and health conscious eating

Approval Workflow

  1. System generates 7-day meal plan based on sales, dietary constraints, budget, variety
  2. Email sent to both adults with meal previews
  3. One denial = meal swapped; no denials = auto-approved
  4. Shopping list generated after approval

Tech Stack

Component Technology
Backend Python 3.11, FastAPI
Database PostgreSQL 15
Frontend React 18, TypeScript, Tailwind
Scraping Playwright, BeautifulSoup
Email SendGrid
Hosting Docker Compose, nginx
S
Description
No description provided
Readme
46 MiB
Languages
Python 72.5%
TypeScript 25.9%
JavaScript 0.5%
PLpgSQL 0.4%
CSS 0.3%
Other 0.2%