fix(add-meal): convert Open Food Facts micronutrients into the app's units - #775
Open
jordan-lee-code wants to merge 1 commit into
Open
fix(add-meal): convert Open Food Facts micronutrients into the app's units#775jordan-lee-code wants to merge 1 commit into
jordan-lee-code wants to merge 1 commit into
Conversation
…units Open Food Facts normalises every `<nutrient>_100g` field to grams, whatever unit the packaging used. This entity carries each micronutrient in the unit the app displays it in: milligrams for the minerals, micrograms for vitamins A, D and B12. `fromOffNutriments` copied the values across untouched, so every mineral was stored a thousand times too small and those three vitamins a million times too small. That is what Genfood saw in #716. Vitamin D read 0.00µg on every Open Food Facts product, in search results and in the Today's nutrients sheet alike, because 5µg had been stored as 0.000005. The daily micronutrient panel sums these same fields and compares them against reference intakes in mg and µg, so a food scanned from Open Food Facts was contributing almost nothing to any micronutrient goal, quietly, without ever looking broken. The other two sources were already right, which is what made the mismatch easy to see once you looked: the Supabase view pivots into the app's units, and FDC publishes these nutrients in mg and µg natively. The same field therefore meant milligrams from one database and grams from another. Two small helpers on the factory now do the conversion, and the tests read it in both directions: the fixtures carry real values from live API responses, and one case asserts that the same food mapped from Open Food Facts and from FDC comes out identical. Meals logged before this keep the values they were saved with. Repairing that history means rewriting someone's intake records on upgrade, which deserves its own change and its own review, so it is filed separately.
|
Thanks. 🙏 Maybe a stupid question, or I don't understand the source code well enough, but wouldn't it be much cleaner to work only with grams regardless of the nutrients? I would propose to only display some nutrients in micro gram on the UI side, and the rest of the calculations, as well as storing them should happen in grams. What do you think about this? |
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
2 participants
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.
Summary
Open Food Facts normalises every
<nutrient>_100gfield to grams, whatever unit the packaging used.MealNutrimentsEntitycarries each micronutrient in the unit the app displays it in, milligrams for the minerals and micrograms for vitamins A, D and B12, andfromOffNutrimentswas copying the values straight across. Every mineral was stored a thousand times too small, and those three vitamins a million times too small.That is what Genfood reported in #716: vitamin D reading
0.00µgon every Open Food Facts product, in search results and in the Today's nutrients sheet alike, because 5µg had been saved as 0.000005.Why it is worth more than the sheet it was reported against
NutrientPanelTotals.fromIntakesis deliberately unit-agnostic. It scales the stored per-100 value and hands the result to the panel, and the panel compares it againstDriReferenceamounts in mg and µg. So a food scanned from Open Food Facts was contributing almost nothing to any micronutrient goal, quietly, without ever looking broken.ComputeRecipeNutritionUseCasesums the same fields, so a recipe mixing an Open Food Facts ingredient with a Supabase one was adding grams to milligrams.Changes
asDoubleOrNull()shape.The other two sources were already correct, which is what made the mismatch legible once you looked at them side by side:
fromSpFoodSummarypivots into the app's units andfromFdcNutrimentsreads FDC values that are natively mg and µg. The same field meant milligrams from one database and grams from another.Type of change
Related issues
Closes #716
Test plan
flutter analyzecleanDetail:
sodium100 == 0.12, against the FDC path's120for the same food).3168930010265and sodium for3017620422003, both reported with_unit: "g".flutter test: 1093 passing.flutter analyze: no issues.What this does not do
Meals logged before this keep the values they were saved with, so old entries read as they do today and nothing gets worse. Repairing that history means rewriting someone's intake records on upgrade, and that deserves its own change and its own review, so it is filed separately rather than folded in here.
Checklist
.envvalues committed