Open wijohnst opened 1 year ago
GET: meal_plan/
interface Meal {
_id: string;
date: Date;
mealType: string;
recipes: Recipe[];
}
type response extends DefaultResponse = {
mealPlans: Meal[]
}
PATCH: meal_plean/meal
type UpdatedMealRequest = {
updatedMeal : Meal;
}
type UpdatedMealResponse = DefaultResponse;
GET: meal_plan/locked_recipes
enum LockableDays = [0, 1, 2, 3, 4, 5, 6];
interface LockedRecipe {
_id: string;
recipeId: string;
mealType: MealTypes;
daysLocked: LockableDays[];
}
type GetLockedRecipesResponse extends DefaultResponse {
lockedRecipes: LockedRecipe[],
}
POST: meal_plan/locked_recipes
interface LockedRecipesRequest {
recipeId: string;
mealType: MealTypes[];
daysLocked: LockableDays[];
}
type LockedRecipesResponse = DefaultResponse;
DELETE: meal_plan/locked_recipes
interface LockedRecipesRequest {
lockedRecipeIdToDelete: string;
}
type LockedRecipesResponse = DefaultResponse;
MealPlan
Whenever the PlusIcon
or a recipe Link
is clicked, the MealPlanDoc
data should be stored in MealPlanner
local state.
const [ targetMealPlanDoc, setTargetMealPlanDoc ] = React.useState<MealPlanDoc | nill>(null)
- MealPlanner.tsx // Top-level local state
| -- MealTable.tsx
Target the handleAddClick
event handler and pass a MealPlanDoc
object to store in top-level state
InlineRecipeCard
ComponentWhen a user clicks a scheduled recipe in the MealTable
, that recipe should be visible from the target MealPlan
.
Pictured, the designs for the updated MealTable
showing an InlineRecipeCard
Lock
FunctionalityThe isolated InlineRecipe
card should have 2 default states:
isLockedRecipe
|| !isLockedRecipe
The buttons and associated click handlers should be dynamically rendered based on Locked
state. The actual implementation will rely on downstream work. At first we can hardcode the component to be !isLockedRecipe
until locked_recipe
functionality has been implemented. DayOfWeekButtonBar
Spillover
Pictured, the DayOfWeekButtonBar
overflowing its container
LockedRecipe
UIHaving returned an array of LockedRecipe
objects from the BE, we now need to update the MealTable
UI to reflect those recipes that are locked vs. those that aren't.
Pictured, designs for a LockedRecipe
In addition to updating the UI, this change should also dynamically control the state of the InlineRecipeCard
component, specifically its main controls.
GET: meal_plan/locked_recipes
enum LockableDays = [0, 1, 2, 3, 4, 5, 6]; interface LockedRecipe { _id: string; recipeId: string; mealType: MealTypes; daysLocked: LockableDays[]; } type GetLockedRecipesResponse extends DefaultResponse { lockedRecipes: LockedRecipe[], }
Implement the enum
LockedRecipes
to targetMealPlan.recipes
when calling MealTable
from MealPlanner
Currently the MealTable
component consumes a MealPlanDoc
object as its targetMealPlan
prop. Every MealPlanDoc
object has a recipes
array that includes the RecipeDoc
objects that exist on the MealPlan
. In its current state this does not include LockedRecipes
, which are not returned as part of the response from GET: meal_plan/
.
Updated MealPlanner.tsx
to fetch the RecipeDoc
objects for all known LockedRecipes
(based on LockedRecipe.recipeId
) and add those recipes to the appropriate MealPlanDoc
.
GET: /recipe/recipes
Endpointinterface GetRecipesByIdsRequest {
recipeIds: string[];
}
interface GetRecipesByIdsResponse extends DefaultResponse {
recipes: Recipe[];
}
Adds the HTTP layer to
MealPlanner
Subtasks
GET : meal_plan/
PATCH : meal_plan/meal
GET: meal_plan/locked_recipes
POST: meal_plan/locked_recipes
DELETE: meal_plan/locked_recipes
GET: recipe/recipes
GET: recipe/recipes
LockedRecipes
totargetMealPlan
Other Tasks
DayOfWeekButtonBar
overflow problem