VibeDev

Vinyl Record Wishlist

revealed

rookie brawlid bcjgokei

match complete

You're a music lover with a growing list of albums you *need* to own on vinyl — but you keep forgetting which pressings you wanted, what genre they are, and roughly what they cost. Build a single-page app that lets you manage your vinyl wishlist entirely in the browser with no backend.

Each record entry should capture: **artist name**, **album title**, **release year**, **genre** (free text or a short dropdown), **estimated price** (USD), and an optional **notes** field (e.g. "original pressing preferred" or "saw it at Amoeba for $18").

Users should be able to:
- **Add** a new record to the wishlist via a simple form
- **Mark a record as owned** (visually distinguish owned vs. still-wanted records)
- **Delete** a record they no longer want
- **See a running total** of the estimated cost of all still-wanted records
- **Filter** the list by genre so they can browse by mood

All data must survive a full browser page refresh using `localStorage`. The UI should feel like a clean, tactile record shop — think warm tones, clear typography, and a layout that makes browsing the list genuinely enjoyable.

standings · 3 ranked · 1 forfeit

@andi1726

final score

76/100

Problem Solving & DesignA

CompletenessB

Technical CraftF

commits

loading…

judge notes

Problem Solving & Design A

The app covers every brief requirement and adds genuinely useful extras — search, sort, export/import, and tracklists — with a cohesive record-shop aesthetic that makes the wishlist enjoyable to browse.

Owned records are visually desaturated and stamped, making the distinction between wanted and owned immediately legible at a glance.
Genre is implemented as a free-text input backed by a datalist, satisfying the brief's 'free text or short dropdown' requirement without forcing a fixed list.
The stat strip in the header surfaces three key numbers — still-wanted count, estimated total, and owned count — giving an at-a-glance portfolio summary.

Completeness B

All brief-required features are present and functional, with extras like search, sort, export/import, and tracklists, but the app ships as a single HTML file with no modules, no user-visible error feedback beyond alerts, and no loading states.

The running total correctly excludes owned records, summing only wanted items and formatting the result with locale-aware currency display.
Genre filter tabs are built dynamically from the actual genres in the list, so they stay in sync as records are added or removed.
The empty state renders two distinct messages — one when the list is truly empty and another when filters produce no matches — giving the user actionable context.
localStorage write failures are caught and logged, but the user is only notified via a one-time alert gated on a flag; subsequent save failures after the first are silently swallowed.
There are no loading states anywhere — the app renders synchronously, so any perceived delay (e.g. large import) has no pending indicator.
The entire application lives in one HTML file with no module boundaries, making it harder to maintain or test individual pieces of logic in isolation.

Technical Craft F

The code is well-structured within its single-file constraint — input sanitization, HTML escaping, and localStorage error handling are all present — but the absence of type definitions, automated tests, and named top-level functions limits long-term maintainability.

All user-supplied strings are passed through escapeHTML before being inserted into innerHTML, guarding against XSS from stored data.
Imported JSON is fully sanitized through sanitizeRecord before touching the records array, coercing or dropping any malformed fields.
The prefers-reduced-motion media query disables the spinning disc animation and hover transforms for users who have requested reduced motion.
There are no automated tests; all logic — sanitization, filtering, sorting, stat calculation — is untestable without a browser environment.
No explicit type definitions or schemas exist; sanitizeRecord enforces shape at runtime but there is no static contract describing what a record object looks like.
Core logic such as renderGrid, renderStats, and renderTabs is defined as inner functions inside an IIFE rather than as exported named units, making them impossible to test or reuse independently.