✏️ Editing a food updates it everywhere you've used it
What we're building:
When you edit a food or recipe you've created, the changes should automatically apply to all the times you've logged that food in the past. This task implements a confirmation dialog that shows you how many past entries will be updated, then applies the changes throughout your food log. The benefit is that if you correct nutritional information or adjust a recipe, all your historical data stays accurate without manual updates.
Requirement
When a user edits a recipe or food item through the Foods view, the app should automatically update all previous instances of that food item without prompting the user. This provides a cleaner UX by defaulting to the most common use case (updating all instances) while still giving the user visibility into the scope of changes.
Acceptance Criteria
- ●When editing a food/recipe in the Foods view, present a confirmation dialog that:
- ●Clearly displays how many past uses of this food item will be updated
- ●Shows the food name and what is being changed
- ●Offers two clear options: "Make Change" or "Cancel"
- ●Does NOT ask "update all instances?" - the default is always to update all
- ●On confirmation, the app should:
- ●Either duplicate the food and re-attach to the meal, OR
- ●Delete the old food and add the new one
- ●Whichever approach is more congruent with the existing sync strategy (review CloudKit sync logic to determine best approach)
- ●After making the change:
- ●The food detail view must reflect the updated values immediately
- ●Verify that all past instances across all meals have been updated correctly
- ●Ensure sync properly propagates changes to CloudKit
- ●Edge cases to handle:
- ●Food with only one past use (verify update works)
- ●Food with many past uses (ensure performance is acceptable)
- ●Editing while offline (verify sync queue handles this)
- ●Concurrent edits (sync strategy should prevent conflicts)
Technical Context
- ●Foods are managed through the Foods view and Food Detail view
- ●The app uses CloudKit for data sync across devices
- ●When editing foods, the app must decide between duplicating or replacing
- ●Previous instances need to be tracked and updated in tandem
- ●Current sync strategy should be reviewed to determine the optimal update approach
Implementation Notes
- ●Review the current CloudKit sync strategy to understand how food updates are handled
- ●Determine whether duplication or deletion+addition is more consistent with existing patterns
- ●Ensure the confirmation dialog provides clear feedback on scope of changes
- ●Verify that all related meals/entries are properly updated after the change
- ●Consider performance implications when updating foods with many historical uses
- ●Make sure preview generation doesn't fail after food updates
Build instruction: Use -destination 'platform=iOS Simulator,name=iPhone 17 Pro' when building this project