Add shopping lists for cooking and crafting pages

[bozheville]

Description

⚠️ Right before opening the PR I spotted there's similar one: #157. Both cover the topic slightly differently and probably the mix would be the best solution. This PR makes no changes and hides the added functionality behind the feature gate, so the functionality may remain hidden while under construction and addresses all the community's needs.

Add the lists of all the ingredients needed for crafting/cooking all the selected recipes.

Demo

Crafting -- no flag (BAU)	Crafting -- with flag	Cooking -- no flag (BAU)	Cooking -- with flag

Hard changes

1. Extract the bundleItemName function and categoryItems list to utils.
2. Unify the filtering logic for cooking/crafting pages.

Soft changes

1. Add the required cooking ingredients list -- only available if feature is enabled or by addding cooking-ingredients query parameter.
2. Add the required crafting ingredients list -- only available if feature is enabled or by adding crafting-ingredients query parameter.

QA hints

Scenario 1

Check the default behaviour -- no changes expected

Scenario 2

1. Open the cooking page with ?cooking-ingredients=1 query parameter -- the ingredients list should appear and only show ingredients for the recipes appearing on the page right now.
2. Open the crafting page with ?crafting-ingredients=1 query parameter -- the ingredients list should appear and only show ingredients for the recipes appearing on the page right now.

Scenario 3

Global rollout

1. Enable the cooking-ingredients or crafting-ingredients or both feature gates.
2. The enabled lists should appear on the relevant page without any query parameters.
3. Add cooking-ingredients=0 or crafting-ingredients=0 query parameter of the relevant page to disable the experimental component.

Suggested rollout strategy

1. Merge & deploy
2. Check the functionality using the cooking-ingredients and crafring-ingredients query parameters
3. Fix bugs found by the fraction of community
4. Enable features for all
5. Fix all the reported bugs
6. Remove the feature gate dependency

[vercel]

@bozheville is attempting to deploy a commit to the stardew Team on Vercel.

A member of the Team first needs to authorize it.

[FracturedShader]

As you noted, this is very similar to what I did in #157. It looks like the main differences are:

• Feature-gated and below recipes vs collapsed-by-default and above
• At top shows total sum of individual ingredients needed vs just counting the number of unique items
• Minimal list format vs expandable item cards
• Sorted by name vs effectively unsorted
• Both support filtering by known/unknown, but this supports full text search whereas mine supports by-season filtering (I also chose to always exclude already cooked recipes, but was considering adding a selection option)
• Does not recursively expand ingredients that are themselves crafted/cooked items (e.g. Complete Breakfast needs a Fried Egg, but that in turn needs an egg)

You also seem to have a better handling of React features than I do (been a while since I've done web dev).

[bozheville]

@FracturedShader you are right, except for one: I do sort ingredients; not by name though -- I sort by number of needed ingredients. The idea is if you need 8 eggs -- it comes before one midnight carp.

The rest is correct.

I didn't to recursive ingredients on purpose. For example you need hashbrowns for dish o' the sea. You don't need two potatoes to cook both. You need one: cook hashbrowns -> add sardines, cook dish o' the sea. Same for the bread and bruschetta.

But I do agree that my implementation is less functional :)

What if I reduce the PR to just have the feature gate, and then we will merge all the functionality both of us implemented? So after we're done -- we open the gate.

[FracturedShader]

Oops, was tracking field indices in my head and just assumed by-name. My bad!

That's a good point on recursion though. You don't need to ship each recipe for it to count, just craft it. That would mean you only need one potato to support the chain of recipes. That makes the need for recursive expansion context dependent. I can't think of any set of recipes that violates the single chain nature (e.g. no two recipes need fried egg), but I don't know for sure.

That sounds like a good plan. I'm torn about the best way to sort things. Alphabetically will make scanning through the list easy to do consistently, but you already have full text search.

I can add the list-specific features into mine with you as a co-author (text search and sorting). Would you be able to add the feature-gating aspect after I've done that?

It might be good to poll a few people on their expectations for how the list would function and any assumed defaults as well. Your feature-gated deployment approach would be a good way to do that.

[bozheville]

Absolutely yes! I am good to integrate the feature gate after you merge your changes.

Do you mean integrating the core feature through the feature gate or updating the feature using feature gates?

Both ways are good, just trying to understand :)

[FracturedShader]

Updating the feature using the gate. Let me see if I can grant you push access to my fork to make that easier. It looks like the changes would primarily be:

• Pulling in the feature gate code (components and such)
• The changes made to _app to wrap everything
• Adding the checks to each page to gate the inclusion of the accordions

Quick aside: I did discover that Hashbrowns are used by more than one recipe.

I'm just about to push my changes to https://github.com/FracturedShader/stardew.app/tree/feature/ingredients-lists, so you should be able to grab them in a few minutes.