Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Food icons for the product page #6387

Open
wants to merge 6 commits into
base: develop
Choose a base branch
from

Conversation

g123k
Copy link
Collaborator

@g123k g123k commented Feb 17, 2025

IMG_2217

@codecov-commenter
Copy link

codecov-commenter commented Feb 17, 2025

Codecov Report

Attention: Patch coverage is 13.00000% with 174 lines in your changes missing coverage. Please review.

Project coverage is 5.89%. Comparing base (4d9c7fc) to head (3d83514).
Report is 782 commits behind head on develop.

Files with missing lines Patch % Lines
.../smooth_app/lib/pages/product/attribute_icons.dart 0.00% 112 Missing ⚠️
...th_app/lib/pages/product/attribute_extensions.dart 0.00% 33 Missing ⚠️
...kages/smooth_app/lib/resources/app_food_icons.dart 50.00% 26 Missing ⚠️
...smooth_app/lib/helpers/attributes_card_helper.dart 0.00% 2 Missing ⚠️
...kages/smooth_app/lib/resources/app_icons_font.dart 0.00% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           develop   #6387      +/-   ##
==========================================
- Coverage     9.54%   5.89%   -3.66%     
==========================================
  Files          325     493     +168     
  Lines        16411   29446   +13035     
==========================================
+ Hits          1567    1736     +169     
- Misses       14844   27710   +12866     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Contributor

@monsieurtanuki monsieurtanuki left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @g123k!

I'm a bit worried about repetitive code, and I'm sure some parts could be rewritten in a more compact and OOP way.

What about icons that are already in assets/cache? With this PR we have duplicates! Would it be possible to use your "new" icons only and to get rid of the old svg files? At least for the icons that are in both folders?

Comment on lines +4 to +10
const FoodIcons.additives({
super.color,
super.size,
super.shadow,
super.semanticLabel,
super.key,
}) : super._(_FoodIconsFont.additives);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All that is very very verbose, for no added value.
What about one single constructor instead?

Suggested change
const FoodIcons.additives({
super.color,
super.size,
super.shadow,
super.semanticLabel,
super.key,
}) : super._(_FoodIconsFont.additives);
const FoodIcons({
super.color,
super.size,
super.shadow,
super.semanticLabel,
super.key,
required FoodIconFont icon,
}) : super._(icon);

Copy link
Collaborator Author

@g123k g123k Feb 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I admit there's a lot of code, but it allows us to have const widgets directly.
Also, for other screens, we may need an "additive Widget" for example

Comment on lines 263 to 276
class _AttributeCeleryIcon extends AttributeIcon {
_AttributeCeleryIcon({
required super.backgroundColor,
required super.size,
super.foregroundColor,
super.semanticsLabel,
}) : super._(
icon: const FoodIcons.celery(),
iconSize: size! * 0.95,
offset: Offset(size * -0.1, 0.0),
clip: true,
padding: EdgeInsetsDirectional.only(top: size * 0.15),
);
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All that is quite verbose and redundant.
Would be easier to read with optional parameters stored at the FontIconFonts level, like:

  • sizeFactor: .95
  • clip: true
  • paddingFactor: Rect.fromLTRB(0, .15, 0, 0)

Comment on lines +16 to +21
'additives' => _AttributeAdditivesIcon(
backgroundColor: backgroundColor,
foregroundColor: foregroundColor,
size: size,
semanticsLabel: semanticsLabel,
),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All that redundant code also could be prevented, cf. later comments.

@g123k
Copy link
Collaborator Author

g123k commented Feb 19, 2025

@monsieurtanuki Following your comments, all icons have:

  • an iconSizeFactor
  • a paddingFactor
  • an offsetFactor

Copy link
Contributor

@monsieurtanuki monsieurtanuki left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @g123k!

Please have a look at my latest comments.

Currently what bothers me more than repetitive code is that you have repetitive icons too: what do you do with the icons currently in assets/cache?

Comment on lines +215 to +220
? EdgeInsetsDirectional.only(
start: paddingFactor!.start * size,
end: paddingFactor!.end * size,
top: paddingFactor!.top * size,
bottom: paddingFactor!.bottom * size,
)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just checking: does it mean that the display will be the same for LTR and RTL?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mmm I don't really understand your point.
The idea of **Directional objects is to manage LTR and RTL automatically, by flipping left & right

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My point here is that for some reason, you sometimes decide to move the icon slightly to the left or to the right, so that it looks better.
That would mean that you say start instead of left, the icon would be moved in the opposite direction, and would look worse.

Comment on lines +301 to +312
class _AttributeEggsIcon extends AttributeIcon {
const _AttributeEggsIcon({
required super.backgroundColor,
required super.size,
super.foregroundColor,
super.semanticsLabel,
}) : super._(
icon: const FoodIcons.eggs(),
iconSizeFactor: 0.65,
paddingFactor: const EdgeInsetsDirectional.only(top: 0.01),
);
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
class _AttributeEggsIcon extends AttributeIcon {
const _AttributeEggsIcon({
required super.backgroundColor,
required super.size,
super.foregroundColor,
super.semanticsLabel,
}) : super._(
icon: const FoodIcons.eggs(),
iconSizeFactor: 0.65,
paddingFactor: const EdgeInsetsDirectional.only(top: 0.01),
);
}
class _AttributeFoodIcon extends AttributeIcon {
const _AttributeFoodIcon({
required super.backgroundColor,
required super.size,
super.foregroundColor,
super.semanticsLabel,
final FoodIcons icon,
}) : super._(
icon: icon,
iconSizeFactor: icon.iconSizeFactor,
paddingFactor: icon.paddingFactor,
clip: icon.clip,
offsetFactor: icon.offsetFactor,
angle: icon.angle,
);
}

Just checking: would that work? Then you wouldn't need all the classes.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your code is correct.
If we want better perf with Flutter, it's always better to have dedicated widgets

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't believe those tiny perf improvements have a significant impact on the overall perf of Smoothie, and I would prefer a more maintainable code.
Your code does work, though.

@teolemon
Copy link
Member

@monsieurtanuki it's a case where we agreed with @stephanegigandet to move faster than the server for icon replacement.

@monsieurtanuki
Copy link
Contributor

@monsieurtanuki it's a case where we agreed with @stephanegigandet to move faster than the server for icon replacement.

@teolemon Nothing wrong with that. But we already have tons of "cached" svg files with similar design and use-cases.
If we're not ready now to get rid of the old svg files, at least we could add a TODO about replacing them with the new font icons.
image

Copy link
Member

@teolemon teolemon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A great visual improvement. Next step is having those in the config screen as well, as it gets revamped.

@g123k
Copy link
Collaborator Author

g123k commented Mar 3, 2025

@monsieurtanuki it's a case where we agreed with @stephanegigandet to move faster than the server for icon replacement.

@teolemon Nothing wrong with that. But we already have tons of "cached" svg files with similar design and use-cases. If we're not ready now to get rid of the old svg files, at least we could add a TODO about replacing them with the new font icons. image

For now, we keep them just in case.
But once the server will use the same UI as us, they will be removed from the app.

@teolemon
Copy link
Member

teolemon commented Mar 3, 2025

Can i merge @g123k ?

@monsieurtanuki
Copy link
Contributor

@monsieurtanuki it's a case where we agreed with @stephanegigandet to move faster than the server for icon replacement.

@teolemon Nothing wrong with that. But we already have tons of "cached" svg files with similar design and use-cases. If we're not ready now to get rid of the old svg files, at least we could add a TODO about replacing them with the new font icons.

For now, we keep them just in case. But once the server will use the same UI as us, they will be removed from the app.

So meanwhile either:

  • it's OK to have different icons in Smoothie for the same purpose - e.g. "may be vegetarian" - one from the server and one from this PR
  • it's OK to keep similar icons with approximately the same name and the very same purpose

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

4 participants