VibeDev

Museum Wishlist: Exhibitions I Want to See

revealed

rookie brawlid f460yfcd

match complete

Build a single-page app that lets art and culture lovers keep a personal wishlist of museum exhibitions they want to attend.

Each entry should capture:
- **Exhibition name** and the **museum / gallery** hosting it
- **City** where it's located
- **Date range** (opening and closing dates)
- A short **notes** field for why they want to go or what excites them about it
- A **status** toggle: `Want to Go` → `Attended`

The list should display all saved exhibitions as cards, with attended items visually distinct (e.g., greyed out or marked with a checkmark). Users should be able to **delete** entries they no longer want and **filter** the list by status (All / Want to Go / Attended).

All data must persist in `localStorage` so the wishlist survives a page refresh. The whole experience lives on one page — no routing, no backend.

standings · 4 ranked

@damosfxa

final score

85/100

Problem Solving & DesignA

CompletenessB+

Technical CraftA

commits

loading…

judge notes

Problem Solving & Design A

The domain model maps precisely to every field the brief specifies, validation is thorough, and the two-click delete confirmation prevents accidental data loss.

The two-step delete arms a button with a 4-second auto-disarm timer, preventing accidental deletion without adding a modal.
The date formatter collapses a shared year so it appears only once, producing compact human-readable ranges like '12 Sep - 20 Nov 2026'.
Attended cards receive a struck-through name and a gold left border, making their visual distinction immediately clear without relying on colour alone.

Completeness B+

Core wishlist features are fully implemented and persist correctly, but save failures are not surfaced to the user and there are no loading states.

Both empty states — an empty wishlist and a filtered view with no matches — are rendered with distinct illustrations and contextual copy, including a call-to-action button.
The filter segment buttons cover all three required states and announce the result count to screen readers via the live region.
Storage write failures are caught and a banner is shown, but the measured gap flags 'errors surfaced to the user' as absent — the save-error banner (banner-write) is wired only to localStorage quota/block errors, not to any user-facing…
There is no loading indicator of any kind; the brief's data is synchronous localStorage so it is not strictly needed, but the practice is marked absent and no pending state exists anywhere in the UI.

Technical Craft A

The codebase is cleanly separated into domain, storage and UI modules with full TypeScript types, a comprehensive Vitest suite, and careful accessibility throughout.

All domain logic lives in pure functions with no DOM or storage dependencies, making every function independently unit-testable.
The storage layer validates every loaded row through the same normalizeExhibition gate used at form submission, so corrupt or schema-mismatched entries are skipped with a user-visible count rather than crashing.
The Vitest suite covers validation edge cases, pure mutation functions, filter/sort/count logic, and date formatting including cross-year ranges and invalid input fallback.
A polite ARIA live region announces every state change — add, toggle, delete, filter — so screen reader users receive feedback without focus disruption.
The failure handling practice is marked partial: loadExhibitions wraps localStorage access in try/catch and surfaces a banner, but saveExhibitions errors are only caught for quota and private-mode blocks — other DOMException subtypes fall…