Implementation of recalculation of ingredients

[christianlupus]

Hello @j0hannesr0th,

after reading your comment, I wanted to separate the technical discussion into a new thread. I also invite @seyfeb and @MarcelRobitaille to participate.

Before I can say if a PR has any good chance of getting merged, I would have some technical details to be hammered out (in concept). Let me ask you a few questions (more will most probably arise):

1. What is your plan for implementing this? Do you want to change only the frontend or do things in the backend?
2. Would you change the API? How about third-party apps? Would there be a change required?
3. Do you intend to change the stored recipe?
4. Is it done on the fly only or somewhere persisted?
5. Could you give a short idea on what you intend to change in order to solve it? I mean especially the interface to the rest of the app not the new business logic itself (that seems rather straight forward).

Thanks for your intention to help here.

[j0hannesr0th]

Hey @christianlupus

Let me answer your questions:

What is your plan for implementing this? Do you want to change only the frontend or do things in the backend?

I only want to change the frontend.

Would you change the API? How about third-party apps? Would there be a change required?

I don't want to change the API.

Do you intend to change the stored recipe?

No. The stored recipe stays as it is. The new feature is only usable, if the stored data is in the "correct" format like 1 piece of butter.

Is it done on the fly only or somewhere persisted?

The stored recipe contains a number (servings) which tells us how many servings the recipe is for. I want to use this number to dynamically (on the fly) calculate the ingredients based on the servings selector:

The „algorithm“ is: amount / storedServings * clientServings

Could you give a short idea on what you intend to change in order to solve it? I mean especially the interface to the rest of the app not the new business logic itself (that seems rather straight forward).

Basically I want to add two buttons + and - - these two buttons in- or decrease the number of servings. When changing the number of servings, the ingredients get recalculated on the client side.

There are a few ways how this can be handled:

• enable the buttons only, if all ingredients have to correct syntax + show a hint why they are disabled
• always enable the buttons and calculate what's possible + show a hint, that the calculation may be wrong due to wrong data format

[Jim8Knopf]

Could you please add also the option to add the Servings as a number? It would be much nicer when I need to calculate for larger groups.

[j0hannesr0th]

Thank you for this good idea:

[seyfeb]

Let me add some thoughts:

Since the implementation as described here solely touches the frontend I see not much harm that could be done.

The long-term question on how to correctly handle ingredients (see the corresponding issues regarding ingredient databases, meal planning/shopping lists, etc.) remains open but once that is solved (which might take a long time) the calculation could be revamped/adapted. Encouraging the users to use a certain structure for their ingredients might even help with an easier migration of ingredient strings to ingredient database items!

A personal opinion: I would like to see some highlighting of ingredients that the algorithm fails to convert, so I know that I have to manually adjust them when cooking.

That said: Since it is a much requested feature, many people would be happy if it were implemented even in the simplest form.

[christianlupus]

I see it similarly to what seyfeb wrote. Without effect back to the server the implications are rather minimal (in terms of possible damage to the user's data) and will not conflict with future updates.

I am not sure, how you plan on transmitting the information from the new Vue component (you will most probably create a new one) to the list of ingredients. It might be done using an event bus. I would rather avoid changing the recipe in the global state.
If you want to do it in multiple smaller steps this might be favorable as it simplifies the review process.

[j0hannesr0th]

I count this as go-ahead and will start soon.

[meonkeys]

Just saw 0.10.3 with the yield calculator. Very cool! I like the "copy" button for the ingredients list, too. Thank you!

One issue I'm seeing is with fractional measurements like ⅓, common in imperial unit cooking (UK, USA, etc). ⅓ now becomes 0.33. There's not a kitchen under the king with a tool labeled "0.33 cup". It's easy to figure out "0.33 cup" is approximately "⅓ cup", but it takes a beat longer to grok an imperial ingredient list when fractions are converted to decimals. And gods help me if I'm trying to make a half recipe with, say "0.17 cup" of something.

It's easy with more common decimals. "½ cup" becomes "0.50 cup": sure, no problem. It seems like imperial recipes are just never written out this way.

Handling fractions would be pain, I imagine. I blame the monarchy.

Side note: I've written some fractions using single "VULGAR FRACTION" non-ASCII characters. ⅓, ¼ instead of 1/3, 1/4, and so on. I see those are not parsed. I blame myself for trying to be too fancy. The unicode database includes numeric values so at least converting to that might be straightforward. On my system if I run unicode 'VULGAR FRACTION ONE THIRD' I see Numeric value: 1/3 included in the output.

I'm happy to file issues for this stuff, just let me know if that would be helpful.

[j0hannesr0th]

Hello @meonkeys, while I'm not a representative of the project, it seems like you've found answers to your own questions, plus some extra insights ^^:

"Handling fractions would be pain, I imagine. I blame the monarchy."

I'm not looking to spark a debate over the merits of the metric system versus the imperial system. However, converting your recipes to the metric system could be a practical solution:

1 1/2 cups of flour ~> 175 g of flour

[meonkeys]

converting your recipes to the metric system could be a practical solution

That's true! Converting my measuring cups, grocery store, friends/family/fellow chefs and brain are other matters, however. 😄

[dcrobertson01]

Which cup do you plan to use? US Cup (237 ml), Imperial cup (284 ml) or metric cup (250ml)?

Personally, I'd like to turn off the conversion of fractions to decimals - 2/3 cup is much easier to read than 0.67 cup.

[neidert]

I find the quantity conversion of the ingredient fields very good. But: Can a code for the beginning of the line (e.g. the existing ##) be taken into account that this line is excluded from the recalculation, that this is a heading line or description line between the ingredients, for which there is also no error message that it cannot be converted?
Thanks!

[j0hannesr0th]

Hi @neidert the solution you want is very easy to implement.

Since the ingredients are basically markdown formatted text we could add something like "if ingredient starts with _ dont make it clickable" -> therefore it won't get strike-through.

cake
1 piece of...
... (other ingredients)
filling
1 litre of...
... (other ingredients)

I can't decide if it will be implemented or not.

[neidert]

Hi @j0hannesr0th
marvellous, that would be just the solution!

Thanks,
neidert

[ewok2]

Hello
This portion calucation is wonderfull, thanks!!!!
I was wondering if you had plan a symbol to be eexclude of this number calculation ?
For exemple If I want to split the ingredient in 2 part I usualy add a "false" ingredient line with "----------------"

Did you have a special caractere to ignore the line (and nat to add the warning aboutr things not calculated with portion)
=> I try the #, ', * without success

[seyfeb]

Try starting the title of a subsection with ##, e.g., ## Sauce !

[ewok2]

Thanks for help but the ## seem's not to works
still this "!" warning that is is not possible to calculate this "ingredients"

[seyfeb]

Sorry, it might be part of the next release since the fix is pretty new. You could either try the current master branch if you are on NC28 or wait for the release. I think it has not been backported to the 0.10.x branch for NC < 28 yet.

[christianlupus]

For the record: this is fixed for master in #1998 and not yet backported.

[ewok2]

Thanks for reply.
NC28 not stable version, I will wait a little ;-)