VibeDev

Craft Beer Cellar Log

revealed

rookie brawlid x09z2jop

match complete

You're a craft beer enthusiast with an ever-growing collection of bottles and cans stashed away to age or save for special occasions. The problem: you keep forgetting what's in your cellar, opening things too early, or buying duplicates at the bottle shop.

Build a single-page **Craft Beer Cellar Log** app that lets you catalog every beer you're storing. Each entry should capture:
- **Beer name** and **brewery**
- **Style** (e.g., Imperial Stout, Barleywine, Sour Ale)
- **ABV** (alcohol by volume percentage)
- **Quantity** on hand
- **Best-by or vintage year** (optional)
- **Personal tasting notes or reason for cellaring** (short text)
- **Date added** to the cellar (auto-filled)

Users should be able to:
- **Add** new beers to the log
- **Edit** existing entries (e.g., decrease quantity after cracking one open)
- **Delete** entries when a beer is fully consumed
- **Search or filter** entries by style or brewery name

All data must persist in **localStorage** so the collection survives page refreshes. Display the full cellar as a clean, browsable list or card grid. Include a running total showing how many individual bottles/cans are currently cellared across all entries.

standings · 1 ranked · 3 forfeit

@fahmifath

final score

78/100

Problem Solving & DesignB+

CompletenessB+

Technical CraftB+

commits

loading…

judge notes

Problem Solving & Design B+

The domain model is cleanly separated, validation is thorough, and the two-step delete confirmation with auto-disarm is a thoughtful UX safeguard.

Delete requires a second click within four seconds; the button text and aria-label both update to signal the armed state, and a timeout automatically disarms it.
Search filters across name, brewery, and notes simultaneously, and combining a text query with a style dropdown narrows results by both criteria at once.
The normalize function validates and coerces every field when loading from storage, silently dropping corrupt entries and reporting a count of skipped items.

Completeness B+

All core brief features are implemented end-to-end; the only gaps are the absence of loading states and that storage errors are shown in a banner rather than surfaced as user-facing inline feedback.

The empty state renders a contextual message distinguishing an empty cellar from a search with no results.
Storage save failures are caught and a banner is shown, but the banner is not announced to screen readers and there is no inline user-facing message tied to the failed action — the user may miss it entirely.
There are no loading states anywhere in the app; because localStorage is synchronous this is rarely visible, but any async extension (e.g. export, import) would have no pending indication.

Technical Craft B+

The codebase is well-structured with TypeScript interfaces, a pure domain module, a comprehensive Vitest suite, and deliberate accessibility and motion choices throughout.

Explicit TypeScript interfaces and a const-asserted STYLES tuple give the domain model precise types that flow through validation, creation, and normalization.
The test suite covers validate, createItem, filterItems, formatDate, normalize, and totalBottles with boundary and edge cases including whitespace-only inputs and coercion.
Card hover and new-card entry animations both include a prefers-reduced-motion override, respecting user motion preferences.
Every form control has a visible label element and aria-required, with per-field aria-describedby wired to live error spans.
CSS custom properties define colours and spacing tokens, but several literal hex values appear outside the token system, reducing the consistency of the shared visual system.