Feature: Categorizing items

[LeoKlaus]

First off, this app looks to become exactly what I searched for, a free, self-hostable alternative to Bring!

I‘d love to contribute in some way. I‘m a fellow computer science student from Germany but don‘t have any experience with Flutter/Dart. I‘m just starting with swift and am very comfortable with Python and C++.

Now the important part:
I‘d like to help implementing the categorization of items. Do you already have a system in mind?

[TomBursch]

Hey Leo,

Thank you for the kind words! Python is definitely helpful, as the backend is build with flask and would need the most work for categorizing items.
I haven't really given much thought into the implementation yet. Bring does some magic with categorization and item icon selection, which I'm not sure how to reproduce without the all the data they're collecting.

One solution could be adding categories to the default items. This wouldn't be very dynamic however. (Also the import of default items is not yet implemented in the frontend)

if you have an idea feel free to share it, or maybe @cMensendiek has some proposals.

Documentation and test-cases are also always welcomed if you want to contribute in that regard.
Thanks!

[LeoKlaus]

I obviously don't know how Bring does it either but it seems to be a rather static implementation.

My guess is they have that (browsable) list of defaults and most of the items have some sort of alias (maybe this uses the default values for product details?).

For example typing Apple in my Bring list will obviously add an Apple with the default choices for details (1,2,3... Pink Lady, Braeburn, regional...). I can however just type "Pink Lady" to get an Apple (without default choices) as well. That Apple will also be correctly matched to the "Fruits&Vegetables" category.

Applying those guesses to your current structure for defaults, it could look something like this:

{
  "items": [
    {
      "name": "Apple"
      "aliases": ["Apples"]
      "details": [1, 2, 3, "1KG", "Pink Lady", "Braeburn"]
    },
  ]
}

The "search order" would then basically be "is there an item with this name?", "is there an item with this alias?", "is there an item with this detail?"

While fooling around with Bring, I noticed you can easily "break" their implementation by using any of these details. Entering "sliced" for example will give you the icon of crisp bread with the category Milk&Cheese.

At first I thought Bring implemented some sort of expression matching, as it usually does pretty well with German compound words like "Reisnudeln". After fooling around a bit, I quickly came to the conclusion that it doesn't. Made up words like "Asdfnudeln" or "Reisasdf" don't get an icon or a category.

I'd love to contribute some documentation, is there anything missing? I don't think I'm familiar enough with your code (yet) to write test-cases.

[LeoKlaus]

I wrote a minimal example of what I was talking about:

items = [
    {
        "name": "apple",
        "alias": ["apples"],
        "attributes": [1, 2, 3, "1kg", "pink lady", "braeburn"],
        "category": "Fruits&Vegetables"
    },
    {
        "name": "noodles",
        "alias": ["spaghetti", "penne", "linguine", "tagliatelle", "farfalle", "rigatoni", "noodle"],
        "attributes": ["1kg", "1 pack"],
        "category": "Grain Products"
    }
]


def find_item(query: str):
    for item in items:
        if item["name"] == query.lower():
            return item

    for item in items:
        if query.lower() in item["alias"]:
            return item

    for item in items:
        if query.lower() in item["attributes"]:
            return item

    return {
        "name": query,
        "alias": [],
        "attributes": [],
        "category": "Custom Item"
    }


if __name__ == "__main__":
    while True:
        query = input("Item? ")
        print(find_item(query))

It works pretty well and is decently fast (with a list of 100,000 items I get a response within .03s).

If I can manage to import the defaults in the backend, I should be able to implement this.

[TomBursch]

To implement this there are a things needed:

1. Item categories (similar to how tags for recipes work but 1:m) .
2. Item description suggestion.
   1. In my mind this would include a table with the description history of an item and suggestions would be based on these. Similar how its done now, the templates would be imported into the db (i.e. attributes in your example).
   2. The search endpoint would also need a description parameter since all of the description is only handled in the frontend currently.
3. The last one aliases. I'm not sure what your idea behind those are, is the goal to search penne and add noodles with the description of penne to your shopping list or know that penne is a type of noodles and as such it is a grain product? Both require different kind of adaptions to the backend.

Generally you're welcome to fork the backend, make edits, and create a PR, If you have a precise idea how this should work.

[LeoKlaus]

I'm not sure what your idea behind those are

My idea was you type Penne and Kitchenowl can provide an icon with noodles and the appropriate category. The Item itself would have Penne as a name and be able to house all kinds of additional details.

This could potentially save a lot of work and redundancy when building the default set.

Especially as I think some sort of alternative name for a product is required. For lack of a better example, I'll just take one from German:
"Clementine" and "Mandarine" are (while technically not the same thing) often used interchangeably, there's no need to define both as a preset item.

A similar issue would be regional differences in dialect, again, for lack of a better example let me take a German one:
"Berliner" and "Kreppel" mean the same thing.

[TomBursch]

Okay I got your idea. That would work, but requires many changes to the existing structure.

One could also allow support for aliases in the importer and just add each alias as an item to the database. This has some flaws too, but only requires small changes to the backend. It would also allow for this:

This could potentially save a lot of work and redundancy when building the default set.

I definitely got some inspiration from this discussion and, if you haven't by then, I will implement a system after I'm done with my bachelor thesis 😄

[irishrain]

After reading the initial message I had a completely different picture of "category" in my mind (I don't know "Bring"). I though you meant categories as "Fruit", "Vegetables", "Dairy". My usecase would be to sort the shopping list by category, making the trip to the store more efficient because things that are nearby in the store would appear clustered in the app. I would not expect predefined categories, as different stores group items differently, so things might end up in different "categories" depending on where you shop.

[LeoKlaus]

My usecase would be to sort the shopping list by category, making the trip to the store more efficient because things that are nearby in the store would appear clustered in the app.

That's the idea, yes.

I would not expect predefined categories, as different stores group items differently, so things might end up in different "categories" depending on where you shop.

That's an absolutely valid point, it should definitely be possible to change the categories as a user.

I'm still writing my exams for this semester but I want to try implementing this later this month.

[TomBursch]

It should definitely be possible to change the categories names and items. However, I think we need predefined categories so the user can start somewhere sane and doesn't have create everything from scratch.

Even without categories we provide a system to dynamically sort the items based on previous trips to the store. Although there is a bug in the current version's sorting and it takes a couple of trips until the sorting improves.