-
-
Notifications
You must be signed in to change notification settings - Fork 325
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
base: develop
Are you sure you want to change the base?
Conversation
g123k
commented
Feb 17, 2025
Codecov ReportAttention: Patch coverage is
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. |
There was a problem hiding this 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?
const FoodIcons.additives({ | ||
super.color, | ||
super.size, | ||
super.shadow, | ||
super.semanticLabel, | ||
super.key, | ||
}) : super._(_FoodIconsFont.additives); |
There was a problem hiding this comment.
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?
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); |
There was a problem hiding this comment.
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
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), | ||
); | ||
} |
There was a problem hiding this comment.
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)
'additives' => _AttributeAdditivesIcon( | ||
backgroundColor: backgroundColor, | ||
foregroundColor: foregroundColor, | ||
size: size, | ||
semanticsLabel: semanticsLabel, | ||
), |
There was a problem hiding this comment.
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.
@monsieurtanuki Following your comments, all icons have:
|
There was a problem hiding this 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?
? EdgeInsetsDirectional.only( | ||
start: paddingFactor!.start * size, | ||
end: paddingFactor!.end * size, | ||
top: paddingFactor!.top * size, | ||
bottom: paddingFactor!.bottom * size, | ||
) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
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), | ||
); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
@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. |
There was a problem hiding this 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.
Co-authored-by: monsieurtanuki <[email protected]>
For now, we keep them just in case. |
Can i merge @g123k ? |
So meanwhile either:
|