[_randyr]

I've also been thinking entirely too much about a good recipe structure.

For now I've ended up on ingredients being more or less recipes themselves, and recipes being recursive (as in, recipes use other recipes to create new recipes). Some recipes you can either buy & make yourself. For example, sweet soy sauce: easy enough to make but you could also just buy it in the store. The resulting structure is basically:

  Recipe:
    directions: rich text
    storageInstructions: rich text
    prepTime: minutes
    cookTime: minutes
    priceEstimateperServing: money
    ingredients: RecipeIngredient[]
    // other fields (e.g. tags, id, name, slug, purchaseableAt, nutrients, etc)

  RecipeIngredient:
    recipeId: reference to recipe
    ingredientId: reference to recipe as well
    // Allows grouping ingredients (e.g. "sauce", although the sauce could be a recipe of its own instead)
    group: string | null

There's some challenges with this though:

- If you have a shopping list, how do you determine in a complex recipe which "recipes" you'll purchase and which you'll make from scratch (UX issue)

- Some recipes may have alternatives instead (for example: if allergic to X, substitute with Y)

- It puts a lot of burden on the recipe writer.

- Some recipes don't scale linearly with just the ingredients, but perhaps also the cookware (baking a cake for example). Cooklang docs talk about this as well.

Scaling of recipes could be done with a measurement-aware type. Something similar to frinklang[0] for example.

[0]: https://frinklang.org/