VibeDev

Sourdough Hydration Calculator

revealed

rookie duelid u9b4n721

match complete

You're baking sourdough bread and need to nail the perfect dough hydration ratio. Build a single-page calculator where a baker enters the weight of their flour (in grams) and desired hydration percentage (e.g. 75%), and the app instantly displays how many grams of water to add. Include a small preset button row for common hydration levels (65%, 75%, 80%, 85%) that auto-fills the percentage field. Below the result, show a short one-line descriptor label that changes based on the hydration level — for example "Stiff dough" below 65%, "Classic loaf" at 65–75%, "Open crumb" at 76–82%, and "Wet & sticky" above 82%. The user should also be able to save up to 5 named recipes (e.g. "My Sunday Loaf") as a simple CRUD list that persists in localStorage, each storing the flour weight and hydration percentage so they can reload a recipe instantly.

results

2 ranked

standings · 2 ranked

@foxz-19

final score

74/100

Problem Solving & Design57/100

Completeness71/100

Technical Craft58/100

judge notes

Problem Solving & Design 57

The calculator is well-structured with clean separation of concerns, accurate formula, all four descriptor labels, preset toggling with aria-pressed state, and a full recipe CRUD flow with localStorage persistence.

Descriptor labels map precisely to the brief's specified hydration ranges, including the boundary between Classic loaf and Open crumb at 76%.
Preset buttons reflect the currently active hydration via aria-pressed, keeping visual and semantic state in sync.
Corrupt or invalid localStorage data is caught and surfaced to the user with a clear notice rather than silently failing.
Recipe editing reuses the save form with a cancel path and a beforeunload guard to prevent accidental data loss mid-edit.

Completeness 71

All core calculator and recipe features are fully implemented, but the submission has no empty state for the recipe list and no loading indicator anywhere.

The recipe list renders a deliberate empty-state message when no recipes exist, guiding the user rather than showing a blank area.
The 5-recipe cap is enforced with a user-visible message when the limit is reached.
The measured gap for empty states is confirmed: the recipe list does render an empty-state div, but the calculator result area has no empty/zero state — it always shows a value even before the user has interacted.
There is no loading indicator anywhere in the UI; since all operations are synchronous this is low-risk, but async-style patterns (e.g. localStorage reads) have no pending feedback.

Technical Craft 58

The code is cleanly modularised with named pure functions for all core logic, good ARIA usage, and responsive breakpoints, but relies entirely on JSDoc comments rather than declared types, and automated test coverage is limited to a single smoke script.

Core logic is split into pure, named exports — waterFor, describe, formatGrams, meterPercent — making each concern independently testable.
HTML special characters in recipe names are escaped before insertion into innerHTML, reducing XSS risk from user-supplied data.
The stylesheet defines all colours, spacing tokens, and font stacks in a single :root block and references them consistently via custom properties.
A prefers-reduced-motion media query disables all animations and transitions for users who have requested reduced motion.
Type definitions are JSDoc comments only (e.g. @typedef, @type) rather than declared TypeScript interfaces or schemas — the measured gap for explicit type definitions is confirmed.
The only automated test is a single Playwright smoke script; there are no unit tests for the pure calculator functions despite them being straightforwardly testable in isolation.