feat: unit-aware ingredient quantities in recipes - #182
Merged
Conversation
Recipes forced grams and prefilled a new line with the ingredient's
serving grams shown AS grams, so a bun read "1 g Rudi's Whole Wheat Bun"
instead of "1 bun".
- An ingredient can name its serving's unit ("bun", "slice", "patty",
"each"; default "serving"), stored on the existing serving amount — no
schema change. The ingredient form gains the field.
- Recipe form lines get a unit dropdown: the ingredient's count unit
(its serving) plus universal mass units (g, oz). A new line defaults to
"1 <serving-unit>" when a serving is declared, else 100 g. The client
computes canonical grams = count × the unit's factor; all nutrition
math still reads only grams, so it is unchanged.
- Lines store the count + unit + preferred alongside grams, so the recipe
detail reads "2 buns" and the form reloads in the same units. The
content pull carries the count too, so the local-first desktop shows
the author's units after a sync.
- Existing rows are read exactly as before — as grams (amount mirrors
grams, "grams" preferred). We do not retro-guess that a stored "1 g"
meant "1 unit"; only new/edited lines use the count model.
Verified: full `just check` green; a live round-trip creates an
ingredient with a "bun" serving unit and a recipe of "2 bun", then
confirms the detail (2 bun / 104 g), the edit reload (units-preferred),
and the content pull all carry the count with correct grams.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Product feedback (7/23): recipes force grams and produce nonsense — "1 g Rudi's Whole Wheat Bun".
The recipe editor spoke only grams and prefilled a new line with the ingredient's serving grams shown as grams. Nutrition math was always fine (everything is canonical grams); the gap was the entry/display unit.
Model — the ingredient's serving IS its count unit
The
amountstable already carriesunit/amount(count) /grams(canonical) /preferred. Grams stays the single source of truth for all nutrition math, so units are a pure display/entry layer.grams = count × factor; nutrition math is untouched.preferred, so the detail reads "2 buns" and the form reloads in the same units. The content pull carries the count, so the local-first desktop shows the author's units after a sync (the web reads the server directly).Migration decision (existing rows — documented, not reinterpreted)
Existing lines were stored with
amount == grams, a "g" label,preferred = 'grams'. They render exactly as before — as grams. We do NOT retro-guess that a stored "1 g" meant "1 unit" (no reliable signal; silently rescaling would corrupt real gram amounts). Only new/edited lines use the count model — re-editing a line lets you switch it to a count unit.Scope
Shipped: serving-unit data model + ingredient-form field + unit-aware recipe form + storage + recipe-detail display + content-pull fidelity. Deferred (documented, non-regressions — they stay grams, which is correct): the inline detail-editor's in-place amount scrubbing and the log add-flow keep gram entry; both can adopt the same picker next.
Verification
just checkgreen — lint, typecheck, web tests, web + desktop builds, all Rust tests, schema-parity + bindings drift.amount 2 / unit bun / grams 104), the edit reload (preferred: units), and the content pull (amount: 2) all carry the count with correct grams.