Code generation

[M123-dev]

Description

A few days ago, I had a good idea about how we could simplify the way we have the project set up right now, mainly the problem with the Product class. We don't know what we can write back & we have to add every field not only there but also in some enums.

My solution would be code generation, in my head I thought of a big JSON file representing every field we could have, with some additional data like if it's writable and a short description so that we maintain a high documentation rate for the pub.dev score. This would even allow to create copyWith or similar function without having to write dozens of new lines of code.

What do you thing of this idea @monsieurtanuki

Tracked in

338

[teolemon]

We have just introduced the beginning of an OpenAPI doc in openfoodfacts-server, which should in theory allow auto-generation of SDKs

[teolemon]

cc @alexgarel

[monsieurtanuki]

@M123-dev Following our discussion on Saturday, I don't know how smart a JSON can be to describe the whole database.

If I focus on a subject that is currently quite interesting to me (Nutriments) because of pending dev (#565 #566), this is what I can say:

• as of today, it's a class with tons of fields, several by nutrient (e.g. for 100 grams, for serving, unit). No one wants to read that.
• currently, there are possible confusions because the name of the fields/labels are not 100% standardized (caffeine is for tag 'caffeine_100g' but energyKcal is for tag 'energy-kcal')
• a bit later, we'll have to handle "product as prepared" data for nutrients, which means again the same 100 grams / serving fields - should we have tons of additional fields? And same thing with "imported"
• some fields are actually read only, like Units (that's not that obvious), and we can get rid of them (the weight input values are ALWAYS in grams) - perhaps providing simple getters with the standard display values, like Unit get calciumUnit => Unit.MILLI_G; and Unit get vitaminB12Unit => Unit.MICRO_G
• Nova has several fields (100g and serving), which does not mean anything as the value is always the same, regardless of the quantity
• as @stephanegigandet pointed out, some fields are computed (and de facto read only), like energy
• we need to add a copyWith method
• we're a bit stuck with a contradiction - we use a JSON / Map<String, double> as input, but using a "normal class" we cannot use whatever code simplification that would bring a Map (e.g. looping on all tags)

In addition to that, I don't believe in generated code in general, I prefer elegant code that anyone can read.

In the particular case of Nutriments, I believe we can code something very elegant (and not a class with 500+ fields). That's what I plan to do in #566.

Which does not solve the specific case of Product that triggered the OP, I'll give you that. But:

• I'm not sure it's feasible to create a big JSON that understands everything
• Even if it's feasible, it's going to take a lot of time, time that we won't be able to use for something more urgent (plus the possible merge conflicts)
• I think the first step anyway would be to clarify all the fields (purpose? read/write, readonly, computed?). Without that we cannot go anywhere.

[M123-dev]

I totally understand your concerns about that @monsieurtanuki all those points.

But for me it's also trying out something new, regardless of if it's worth at the end or not. If I have some free time I'm going to test around with it. At first for a copyWith so that we don't have a problem with depreciation. And if it turns out to be not good we can just scrape it.

[monsieurtanuki]

Ok then!

[stephanegigandet]

• we're a bit stuck with a contradiction - we use a JSON / Map<String, double> as input, but using a "normal class" we cannot use whatever code simplification that would bring a Map (e.g. looping on all tags)

Why don't we just do that in fact? Keep a map with string identifiers for nutrients, instead of creating specific fields for each nutrient... We can just specify a list of string constants for those identifiers so that we avoid typos. and instead of having separate fields like saturatedFat etc. we can just have getter/setter function like getNutrientValue(SATURATED_FAT, PREPARED, PER_100G).

It makes a lot of things much easier. For instance on the website, we display different nutrients in differing orders in different countries, because the default US nutrition facts table is different than the India nutrition facts table and from the EU nutrition facts table. So we can just have a list of nutrients to display for the different countries. If we don't have a getNutrientValue function and instead need to directly use fields like saturatedFat, it makes things more complex.

[monsieurtanuki]

@stephanegigandet Actually I'm currently implementing that for #566:

• in Smoothie I was already cheating as I used the json instead of the class fields, for read and write
• in Smoothie we already use a different order depending on the country, and we use the tags (e.g. 'vitaminB2' for that)