VibeDev

Spice Rack Inventory

revealed

rookie brawlid 72bjilk0

match complete

You're tired of buying duplicate jars of cumin or discovering your paprika expired two years ago. Build a single-page **spice rack inventory app** that lets a home cook track every spice and seasoning they own.

Each entry should capture: the spice name, quantity or fullness level (e.g. full / half / almost empty), an optional expiry date, and a personal notes field (e.g. "smells weak, replace soon").

The app must persist all entries in `localStorage` so the list survives page refreshes. Users should be able to:
- **Add** a new spice with the fields above
- **Edit** an existing entry in place
- **Delete** a spice they no longer have
- **Filter or sort** the list (e.g. show only "almost empty" items, or sort alphabetically)

Make the UI feel like a real kitchen tool — warm, clean, and scannable at a glance. Highlight spices that are almost empty or past their expiry date so the cook knows what to restock on their next grocery run.

standings · 4 ranked

@damosfxa

final score

76/100

Problem Solving & DesignB+

CompletenessA

Technical CraftC

commits

loading…

judge notes

Problem Solving & Design B+

The app cleanly covers every brief requirement with thoughtful UX touches like the fullness meter, amber/red restock highlights, and a count badge showing filtered vs total spices.

The fullness meter uses a role="img" with an aria-label and a CSS width driven by the level's ratio, giving a scannable at-a-glance visual for each card.
Expired and almost-empty cards receive distinct left-border colours and gradient backgrounds, making restock candidates immediately visible without reading text.
The expiry comparison treats today as not-yet-expired, matching the natural expectation that a jar expiring today is still usable.

Completeness A

All brief-required features are fully implemented and the app surfaces a toast for storage failures, but form validation errors are the only user-facing error path — broader runtime errors are not surfaced.

The two-step delete confirmation prevents accidental data loss and is keyboard-accessible, with focus moved to the confirm button automatically after render.
Storage write failures are surfaced via a toast, but any other runtime error (e.g. a crash inside render or onListClick) is silently swallowed by the browser with no user-visible message.

Technical Craft C

Logic, storage, and DOM are cleanly separated into ES modules with JSDoc annotations, automated tests cover the pure functions, and the CSS design-token system is thorough — but the measured tooling gaps (TypeScript/schema types and a test runner) are absent.

loadSpices re-validates every entry from localStorage through the same createSpice validator used for new input, so corrupt or schema-mismatched stored data is silently dropped rather than trusted.
All design tokens — colours, radii, shadows, speed, and font stack — are declared once in :root and referenced via var() throughout the stylesheet.
The escapeHtml function is applied to every piece of user-supplied data before it is inserted into innerHTML, including the stored id field.
The reduced-motion media query disables all transitions and animations globally, and the toast delay is also extended for those users in JS.
JSDoc @typedef blocks provide inline documentation but there are no TypeScript declaration files, Zod schemas, or equivalent explicit type definitions that a type-checker can enforce at build time.
test.js contains a hand-rolled assert/throws harness rather than a recognised test framework, so the tests are not discoverable by standard CI tooling and the measured gap for automated tests stands.