Extract useful widgets as a Pub.dev package

[teolemon]

We had this plan a long while ago to extract both the backend logic (we did that with openfoodfacts-dart) and the nutrition/food specific user interface (nutrition display, nutrition input, ingredients extraction, …).
Somehow, we lost track of this "openfoodfacts-mobile-ui", and I think that it would be a good time to separate things, as we get ready to embark on the visual revamp.

• It would entice us to clean the code/widgets as we make them available for 3rd party use (just like for the network queries)
• It would unlock opportunities for fast iteration for 3rd party apps, and unlock more data contribution.

Candidates for extraction could be: knowledge panel widgets, such as nutrition table… editing widgets, road to scores, robotoff, and possibly more as relevant.
We would ensure that 3rd party developpers can reskin everything at will, and we would apply our own theme on top of it.

@monsieurtanuki @g123k @M123-dev what do you think ?
@MohamedFBoussaid , others: would such a thing be interesting to you ?

[monsieurtanuki]

@teolemon I'm not in favor of a pub.dev openfoodfacts-mobile-ui, and I'm going to tell you why:

• we already have enough work to do in the app, and not enough dart/flutter coders (basically only 2, with some extras from time to time). We cannot afford to add friction to the process.
• what you tacitly imply is that there's a perfect way to display for instance nutriscore, and that all apps should take ours as is or be able to make some adjustments on top of it. I don't think there is, and I don't think they should.
• we already have open issues about refactoring (e.g. Don't use FutureBuilders #4882 Multiple folders for the same thing? #4918) and as interesting as they may be, they are not a priority compared to new features or bug fixes.
• that supposes that there are enough flutter apps about food that would be interested in that.

On the other hand, providing clean examples of code based on off-dart could indeed be interesting, for us and for other developers, in order to "unlock opportunities" as you say.
What we do in osmdroid is that we provide a sample app, something like a menu to test all features (offline map, zoom, tile layers, ...), which gives an idea of what can be achieved and how to code it.

Basically, my suggestion is similar to yours but instead of saying "this is the correct way to display the nutriscore and you can reuse it", we would say "if you want to display the nutriscore you can do that and it's easy".
The difference is huge in terms of taking into account all the "what if"s that other developers may need.
It's also much better to be relaxed about this new package, and will give much freedom to inventive developers, like "hey I've just found an interesting way to display nutrition data and I share it with you: don't consider it as a standard and feel free to reuse it".

Still, I don't think we have time for this but that's another story.