suchapalaver / gust Goto Github PK

gust currently only supports requests for recipes from the BBC Food website.

For example Groceries contains write_to_file, read_from_file, and get_sections. These aren't really specific to the impl for a given instance of Groceries. It feels like maybe these should be made into a module rather than an impl block.

Check out guidelines for docs, Documentation tests, More API documentation

• common

Right now clap isn't being used particularly correctly. Let's aim for arguments like the following for a start:
cargo run -- recipe new "tofu chicken rice" --ingredients tofu rice chicken garlic
And have the same minus the --ingredients flag run a default that asks the user for ingredients input

Currently we have a rigid system using:

pub const SECTIONS: [&str; 5] = ["fresh", "pantry", "protein", "dairy", "freezer"];

This should be flexible according the user.

Below is just one example where we're inefficiently inserting using on_conflict_do_nothing to ensure that an item is present in our store, a good example of the kind of path of least resistance that doesn’t lead to a good place.

//! crates/persistence/src/sqlite/mod.rs

fn get_or_insert_item(
    &mut self,
    connection: &mut SqliteConnection,
    name: &str,
) -> Result<i32, StoreError> {
    diesel::insert_into(schema::items::table)
        .values(NewItem { name })
        .on_conflict_do_nothing()
        .execute(connection)?;

    let item_query = schema::items::table.filter(schema::items::dsl::name.eq(name));

    Ok(item_query
        .select(schema::items::dsl::id)
        .first(connection)?)
}

For example you have:

struct GroceriesSection {
    section: String,
    items: Vec<String>,
}
struct Recipe {
    recipe: String,
    ingredients: Vec<String>,
}
struct ShoppingList {
    recipes_msg: String,
    recipes: Vec<String>,
    checklist_msg: String,
    checklist: Vec<String>,
    list_msg: String,
    list: Vec<String>,
}

Here the types do not make clear which items are used in which places. For example GroceriesSection::String is totally unrelated to the items in Recipe::ingredients. However GroceriesSection::items is the same. So rather than all of these being just String you could have types like:

#[derive(Shrinkwrap)]
struct RecipeName(String);
#[derive(Shrinkwrap)]
struct Ingredient{ name: String }
``
etc. (using shrinkwraprs 3)
This would make things like `ShoppingList` much easier to understand by looking at the struct.

Errors aren’t specific enough right now. Good example if there’s some problem with the JSON files.

Adding the same recipe, for example by running make fetch url=https://www.bbc.co.uk/food/recipes/vegetable_noodle_pancake_22079 twice will result in something like this:

2023-12-28T18:15:32.603913Z ERROR api: API dispatch, error: StoreError(DBQuery(DatabaseError(UniqueViolation, "UNIQUE constraint failed: items_recipes.item_id, items_recipes.recipe_id")))
    at crates/api/src/lib.rs:104

I'm not a huge fan of running through asking what operation you want to perform. Maybe you could look into using subcommands with the clap crate, so if you want to add a recipe to the library you don't have to enter n a bunch of times.

You could also make a help subcommand that prints some info and maybe with no subcommand you can run the same process you have.

Once you have them broken into subcommands you'll see that running one after the other looks much cleaner too.

https://crates.io/crates/question

this would reduce repetition of code among other improvements--see this tutorial: https://sodocumentation.net/rust/topic/1762/error-handling