Shopping list design

Hi all!

I am creating a recipe app that will have a shopping list feature that will, when a user hits a button on the recipe card, will transfer the Ingredients from the recipe to a Shopping List table. The shopping list is a collection of ingredients from one or more recipes, and should there be ingredients that have the same product (ie Celery) and unit (ie cups), it will sum up that product and unit. Otherwise, if the product is the same and the unit is different, it will list it as separate items. In addition, some recipes might have two instances of the same product in the ingredient list, and the same idea applies to those.

Is there a better way to design this feature? Currently, I have got so far as to add the ingredients to the shopping list from the recipe card, but I am not sure how to proceed with summing up each unique item. Should I create another table to filter by product and then sum? Or maybe a way to sum it up as it is adding to the Shopping list? Any ideas or suggestions are very much appreciated.

Ingredients Table

Shopping List Table

Actions:

Add To Shopping Cart: Attached to Recipe card. Calls the Transfer Ingredients To Shopping List Action to operate on Ingredient Rows that refer to the same Recipe ID as the current recipe.

Transfer Ingredients: Attached to Ingredients table. Transfers each row to the shopping list table.

I think you are on the right track. Personally, I would probably take the path of checking if a Product row exists in the Shopping list. If it doesn’t then add it. If it does then update it.

The updating gets tricky. AppSheet enhanced the “add a row” action so it can add or update. It will update if you supply the row ID/Key. However, if you are updating you must provide all column values that do not automatically update or they will be over-written with blank values. I have experienced some other issues just today and abandoned using the “update” option of that action. Instead I created another approach to updating.

Another option for your use case might be to attach to the Shopping product row a list of recipe product rows. Then you can SUM the quantities from the recipe list to get the Shopping quantity. The side benefit is that you can provide to each user a way to easily see which recipes contributed to the shopping list - even for each product. An additional challenge might be how to handle items added that are NOT part of a recipe.

Are you still working on this/did you figure it out? I would love to see a template of what you came up with. I’d like to make a similar thing.

I replied to a similar inquiry here.

I modified the solution a bit so a control table is no longer required.

Instead, add a column [summary.owner] to the QUOTES table that is set to USEREMAIL() to indicate which QUOTE is being summarized.

I also extended the BOM table to accommodate UNITS.

This is the bot that is fired when the QUOTE’s [summary.owner] is set.

The first step copies required materials from BOM along with relevant QUOTES and QUOTES_DETAILS data to an intermediate table QUOTE_MATERIALS.

The action called in this step is

Here you see that [summary.owner] is used to identify the QUOTE being processed.

A similar idea with QUOTE_DETAILS. Notice also that [unit] is added to the constraint clause.

The second step calls an action on the very QUOTE that initiated the bot, which in turn calls an action on QUOTE_MATERIALS to summarize materials and write the results to QUOTE_MATS.

This is the action on the QUOTE.

This Referenced Rows expression is critical in identifying only one row for each of unique material + unit combinations which is copied to QUOTE_MATS along with a SUMMED quantity for that material + unit combination.

The LAST step is not strictly required but it just clears [summary.owner] to deal with multi user situations.

Animation.gif

Hope this will give you something to work with.