Refer to #3 for discussion of implementation.

Proposal

Introduction

This proposal outlines a method by which data for recipe instructions can be encoded within a database. It will utilize a stringified JSON object, which can be deserialized on the Astro server-side or the Tauri backend (preferred, translated into markdown and served via request on client-render(?)).

The Instructions Interface

This interface describes the general first level of a recipe Instructions object. This object describes the basic information, such as the name, author, date of writing, etc. It will also contain a property for variations and recipe-building instructions.

interface Instructions {
    name: string;
    author: string | Author;
    date: DateTime;
    // etc...
    sections: RecipeSection[];
}

The Instructions.sections Entry Array & RecipeSection Interface

This interface describes each section of a recipe, whether there is just one big section or a bunch of small ones. Each object encodes the name of the section, the ingredients and quantities, an index, and the itemized steps.

The index property is used to test for collisions, leading to two options: one variation or multiple variations at the same index. For example, when making Вареники, since only one dough type is used, and it is first in the order, it has index: 1. However, since different fillings exist, such as cherries or cottage cheese, they can all be placed at index: 2. The collision can be detected by mapping each index to an array and testing the length. If length > 1, then the user needs to choose between the items in the array.

interface RecipeSection {
    name: string;
    index: number;
    subtype?: string | SubtypeEnum;
    ingredients: {} satisfies Record<string, string>;
    steps: Array<string | RecipeSectionStep>;
}

interface RecipeSectionStep {
    instruction: string;
    photoSrc: string | URLResolvable;
}

Amendments may be made later, but let me know what you think!

Goal: To come up with a standard format to follow when it comes to changesets. Add a comment to this issue with a list of things each of us would like to see mentioned as part of the changeset summary. This list will be used to create the standard.

The following is the roadmap for creating recipes:

• Step-by-step on-boarding process.
• Ask for recipe name.
• Ask for ingredients w/ Preparation and Cooking time.
• Ask for instructions.
• Cross-check instructions with ingredients list.
• Ask for Recipe image.
• Provide Summary of Recipe.
• Add to database.

The following is the roadmap for viewing recipes:

• Timer Functionality to track time (Refrigerate for 20m)
• Cook Counter (Fun Easter Egg)
• #4

The following is the roadmap for app behaviour:

• Open multiple instances or windows with multiple recipes.