Categorized Ingredients

[Grygon]

Putting together a discussion to collaboratively design what I plan to be a series of PRs.

Before submitting this feature request I have
COMPLETE AND FILL THESE OUT

• Reviewed the documentation and verified that my feature request isn't already a feature.
• Reviewed the existing feature requests and my feature has not been requested.
• Checked the tasks taged issues and verified my feature is not covered

Please Describe The Problem To Be Solved
With the new concept of a defined "Ingredient" that exists now in mealie-next, we should take advantage of these as objects that can have associated, useful data. Specifically here, we should have the ability to Type ingredients, in order to allow grocery-list-level grouping for easier shopping, akin to how other sites like CopyMeThat do:

(Optional): Suggest A Solution
To implement this, we'll need a few things:

Update Foods:

1. Change how we access foods from ID-based to Slug-based, to make it more intuitive and simple (/api/foods/apples, not /api/foods/4)
2. To avoid needing to PUT in any changes here, adding the GET/POST route /api/foods/{slug}/properties. This will return an array of all property:value pairs on the food, and can be POSTED to in order to update said properties. See below for definition of properties. An example return (with a custom type added, which won't be UI-supported immediately):

[
    {
        property: "type",
        value: "Fruit"
    },
    {
        property: "Perishable",
        value: "Shelf-perishable"
    }
]

Add FoodProperties

1. To keep things simple, usable, and safe, FoodProperties will just be a simple key:value pair where all values are defined enums, of which only one can be selected. I think that's the best path forward here so we don't have people trying to handle strings etc here, and will simplify the UI both in this first wave and any future integration that might be wanted with the FoodProperties.
2. This will be using standard CRUD as well, so can just extend off that nicely. Properties will also be slug-based access for ease of use, and I think we can get away without needing an ID at all which would work well here.
   Very simple datatype:

interface FoodProperties {
    key: string;
    values: Array<string>;
}

We'll include one FoodProperties built-in to start in order to address the "grouped shopping list" approach, named "Type". I'm thinking the following values by default, although of course they could be edited via API:

1. Alcoholic
2. Bakery & Bread
3. Canned, Jarred, Preserved
4. Cheese
5. Condiments, Oils, Sauces
6. Dairy, Eggs
7. Herbs, Spices
8. Protein
9. Pasta, Grain
10. Produce
11. Snacks
12. Frozen
13. Other

To begin with, there will only be support for this FoodProperty to keep the main use case in mind, and which will be implemented on the frontend as so:

• A page that lists all Foods and their associated Type. Blank if none is selected, with a dropdown to select the association. Standard scrolling functionality etc should apply, like AllRecipes. Should also have the ability to search, and only show a given category (including blank)
  • Could be a good more general "Food admin" page for deleting foods etc at some point
• Grouping the Shopping List by the FoodProperty Type values. Headers will only be displayed for values that exist on the Foods in the list, and if only one value exists no header will show.

Note: This is overkill for the intended purpose, but I think there's a lot of future value in this framework

A few things that came to mind for that eventuality:

• Perishable status (Frozen/Refrigerated/Shelf-Perishable/Shelf-Stable/Long-Term Stable) to allow people to more easily identify recipes that they could always keep ingredients for on-hand
• Estimated cost of 1 [standard unit], although "standard unit" may not be something that would work. But that way people could group recipes into lower/higher cost things
• Types could cover it a bit with a little extension beyond what's laid out above, but being able to classify things by the store to buy them at would be great (e.g. "Only buy at Asian Food Store"/"Buy at Costco if at all possible")

Additional Information
FILL THESE OUT

• If the feature is accepted I'm willing to submit a PR to provide this feature

[braddillon]

First off, great idea! I would love to see this implemented. A few items of feedback/questions.

Default types
Add Deli.
Break protein out into Meat and Seafood.
Break produce out into Fruit and Vegetable
Some sort of category for Home item? (Dish soap, laundry detergent, shampoo, etc. etc.)

Ordering
Would it be possible to assign order to the food properties on the shopping list? (E.g. Fruit first, then vegetables, then dairy, etc.). Grocery stores aren't often arranged alphabetically.

Other properties to consider
Ignore -- Would be ignored when adding recipe to shopping list. Think salt, pepper, other dry spices, that you know you always have on hand.
Staple -- When making shopping list, bring up list of food items marked as staples. You can quickly scan through them and add what is needed.

Food Type properties vs Metadata properties
How would we handle having food type properties (fruit, veggie) in the same table as metadata properties (ignore, staple, shelf-stable, perishable). Would that cause grief to the shopping list arrangement?

Long term considerations
Would we ever want to be able to generate different shopping lists depending on which grocery store we are walking through? GroceryA arranges things differently than GroceryB. It would be cool to pick the grocery store you are in as you open the shopping list, and it arranges appropriately.

I think this would require a GroceryStores table, and perhaps a GroceryStoreSection table. Many grocery stores may not respect our food types. E.g. GroceryStoreA keeps cheap cheeses on one side of the store, and fancy cheeses on the other side of the store.

Each GroceryStoreSection could be assigned a default Food type. Then if people wanted they could provide specific grocerysection overrides. Shopping list would search the override list, and if it didn't exist then use the default.

Of course this could be way overkill. ;)

[Grygon]

Default Types

Deli's a good idea!
I like Protein because you'll probably only need so many types of protein in a given trip, and having Meat & Seafood seems (to me) like you'd end up with one or the other fairly empty. Plus it's inclusive of meat alternatives. If there are strong feelings though that's open to change, personally I'd only be using it for meat alternatives so I may have a mistaken impression of how much it might actually get used
I like the produce split, adding
Home... I went a bit back and forth on adding that originally because there probably won't be any recipes that use any Home items, so it would really just be manually or API-added items, so could fit well in Other. I'll add it though, but open to further discussio

Ordering

That could probably be done by the index of the Values property. Not directly-editable in this first wave, but would be more configurable with a FoodProperties UI (which I don't plan to implement immediately). Unfortunately, sensible defaults here would be tough, since grocery stores can be laid out so differently--most would start with produce etc, but not all, and then it would keep getting complex pretty fast.

Other

Good idea for some future ones--and that brings up a good point, that we could have bool-like Properties and do some neat things. But I'm going to leave that out of the scope for now so it doesn't get too complex.

Metadata

It shouldn't! I've added an example to the main post of what an example return of /properties will look like. In this first pass, the shopping list will just look for a value with a property of "type" and ignore anything else. Future configuration would be good though, but don't want to get too complex for now.

Long Term

Would also be very nice, but yeah that would get... complex. Could use something split out into sub-types, like "Type-StoreA" which adds the distinction between fancy/cheap cheese, while "Type-StoreB" doesn't have any Types for fresh food, but more detailed versions off all the grains/preserved/etc things. Good ideas for a future enhancement on top of this though.

[Rhyn]

I would consider adding alternate names/spelling as property for every ingredients. Maybe even a merge ingredients functionality. It would make parsing imported recipes easier and would result a less messy ingredients list on the long run

[hay-kot]

Initial Thoughts on your Post.

Change how we access foods from ID-based to Slug-based, to make it more intuitive and simple (/api/foods/apples, not /api/foods/4)

I don't think this is a good approach. While it's easier for humans to read, it makes the overall process in the code more complex and requires additional code. I don't know what the actual benefit of that would be? Since we're not typically going to be sharing ingredient URLs, I think this just adds complexity without much benefit.

To keep things simple, usable, and safe, FoodProperties will just be a simple key:value pair where all values are defined enums, of which only one can be selected. I think that's the best path forward here so we don't have people trying to handle strings etc here, and will simplify the UI both in this first wave and any future integration that might be wanted with the FoodProperties.

Why a key/value store vs a defined category-like table in the database? If we added an ingredient category table that could link to multiple recipes, I think that would offer much more flexibility. It would make filtering ingredients much faster on the backend instead of doing some custom query. I understand this would let you set any number of properties, but I'm struggling to see the utility of that longer-term.

We'll include one FoodProperties built-in to start in order to address the "grouped shopping list" approach, named "Type". I'm thinking the following values by default, although of course they could be edited via API:

I really like the idea of pre-populating common categories (or whatever) keep in mind that I've added similar functionality for Ingredients so we can build off of that structure. On a future note, those will also need to be made available for translations.

A page that lists all Foods and their associated Type. Blank if none is selected, with a dropdown to select the association. Standard scrolling functionality etc should apply, like AllRecipes. Should also have the ability to search, and only show a given category (including blank)

There's an admin page for Food and Units on the admin panel. https://beta.mealie.io/admin/toolbox/foods We can build off of that

---

Here's What's Been Floating Around in my Head on this Topic

1. I see 2 key things that could provide a lot of utility for more advanced users. Ingredient Categories, and Shopping List Links
   a. Ingredient Categories would function nearly exactly the same as recipe categories. We could ship default categories with the initial installation and the rest could be user-defined. Inside of a shopping list, items would automatically be sorted by category.
   b. Shopping List links would work in that you could define a Specific Shopping List as a destination for an Ingredient. Users would link an already created shopping list to an ingredient and that ingredient would always be added to that shopping list.

Note that these would be a one-to-one relationship. I don't think there's an effective way to allow for multiple categories of ingredients. Also, I think we should call them Ingredient Labels /Labels to avoid confusion...

2. I'm not convinced that a wide majority of users would use this feature, so we need to make shopping lists flexible enough to be used without ingredients. Not sure about how this would go, but something to keep in mind.

3. As for PRs I think that really getting the ingredients fleshed out would be the first step. From there I think the shopping list will take shape directly from where we get with the ingredients.

Excited to see where this one goes, thanks!

[braddillon]

Another nice thing about the ingredient category table is that it should be relatively easy to include a preferred sort order of the categories.

[Grygon]

Finally getting some time to respond here...

Slug-based food

Fair enough, I was thinking it could simplify any client-side access that might need to be done but that's probably unnecessary.

Category Table

Hm... I do really like the flexibility offered by the "arbitrarily extendable solution" but maybe I should keep scope to this specifically for now, especially since this is probably the property that would need to be most performant. If we need to re-visit later to add arbitrary properties, it may be best to approach those differently anyway since they'd be very much of a power-user feature and wouldn't be as frequently accessed

Pre-populating

Sounds good 👍 Also, a table would simplify any translating we may need to do

Admin page

Great to hear there's a starting point, that simplifies that piece quite a bit

[hay-kot]

💯 Looking forward to seeing what this turns into. Some-what of a side note, if you're having problems with the auto_init decorator, let me know before you make any changes. I've got a PR where I've made a ton of changes to fix some underlying bugs with it. Hoping to get that merged this week.

[tjjunior]

I did something similar in another recipe program https://github.com/nazgul26/PHPRecipebook. In the shopping list, ingredients were grouped by category as described above (Cheese, Dairy, Baking, Canned Veggies etc). My solution was to add 2 tables, one to store user-entered store names (Store X in City Y), and a second table to store Aisle numbers and Sort Order by Grocery Store by Category.

• User enters Publix Grocery store in City Y as a new store.
• Once that store is entered, user can then designate that for that specific store, Cheese is in Aisle 1, Canned Veggies in Aisle 2, Baked Goods in Aisle 7, etc
• When the user creates a shopping list, they are asked if they want to specify which store they are going to. If not, it does a default sort order. If they do specify the store, it sorts the shopping list by Aisle # (or more specifically a sort order, as some items may be on the Back Wall or left side rather than a specific aisle, so you'd want a way to sort those).

Now, when you print the shopping list, the list is now sorted so you can move through the store quickly from left to right, skip aisles that you don't need, and know exactly which aisles you do need to go down.

[hay-kot]

I've made some partial progress on implementing the shopping-list feature in the mealie-next branch. Still lots to do, but I'm taking a break to work on some other parts of the app. I would greatly appreciate anyone's help on making progress on the shopping lists.

• [v1.0.0b] [Task] - Implement Shopping lists #916

[Handkep]

Hi there, is it implemented?

[michael-genson]

Yes, there are several features related to this. Shopping lists will auto-categorize your items as long as your food store is set up and foods are assigned labels

[Handkep]

Sorry to bother you but I can't find this feature in the documentation. Can ingredients be organized?

[michael-genson]

Yes, make sure your foods/labels are set up: https://docs.mealie.io/documentation/getting-started/faq/#how-do-i-enable-smart-ingredient-handling

Then when you add shopping list items they will be labeled according to your food store. To organize by label, make sure you've toggled sorting by label:

[YourLastFate]

Im having a difficult time finding the tag you've shown in your image, as well as figuring out how to add a 'food store' at all.
Ive followed your link, and googled/combed the documentation as much as I can, but I cannot find any way to add a food store.

I am hoping to allow a parser to best decide what label each food should receive. Is this an option that is presently available?

[michael-genson]

The food store is in the data management page: https://demo.mealie.io/group/data/foods

The label sort option has moved:

[delize]

Hm, has this been implemented on the Recipes page?

For example, is there a way to obtain a similar "categorization" on this page with this feature request? Or is this out of scope for this feature request? I was previously going to make one, but, then started searching and this seems like it is the closest related item (or otherwise this: #3371

[michael-genson]

Yes, you can add sections to ingredients. You have to click the three dots next to the ingredient while editing