Added restaurant card implementation #1398
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## ui/redesign #1398 +/- ##
===========================================
Coverage 12% 12%
===========================================
Files 266 266
Lines 7201 7201
===========================================
Hits 806 806
Misses 6395 6395 |
|
@abutuc can you add screenshots of the result? |
|
Use TabBar in order to build and implement the top bar |
| } | ||
| } | ||
|
|
||
| class RestaurantCardHeader extends StatefulWidget { |
There was a problem hiding this comment.
Extend StatelessWidget instead. The state should be managed in the uni_app package, and passed as a boolean argument (isFavorite) to the RestaurantCard, along with a void function / VoidCallback (typedef VoidCallback = void Function();) to handle the favorite icon click.
(if a StatefulWidget were to be used, it should be limited to managing only the state of the icon itself)
| break; | ||
| default: | ||
| iconType = cow; | ||
| } |
There was a problem hiding this comment.
According to previous discussions, uni_app should "send" the icons to the RestaurantCard component. Therefore, the icons should be passed as an argument.
| ); | ||
| } | ||
|
|
||
| class MenuItem { |
There was a problem hiding this comment.
To avoid introducing models in the uni_ui package, I suggest creating a MenuItem widget in uni_ui instead of defining a MenuItem model (that would take parameters like icon and name) and handle the display logic for each menu item. The RestaurantCard would then receive a list of MenuItem widgets, and uni_app would be responsible for creating and passing this list.
What do you think?
There was a problem hiding this comment.
I'm a bit skeptical and I do not like the idea of having models in the ui, so you got a point there. However, if I understood what you're saying, we'd have to create a model in the ui and follow the following path: create in ui -> instantiate in app -> pass to ui, which is a bit strange.
Either way, or that or passing all the information destructured.
There was a problem hiding this comment.
To clarify my point: instead of defining any model in the uni_ui package, we should create a widget that takes attributes like icon and name as parameters. The RestaurantCard would then receive a list of these widgets.
There was a problem hiding this comment.
I agree with @vitormpp. MenuItem can be a widget and the restaurant card receives a list of MenuItem widgets
Closes #1274
Added the redesign implementation of the restaurant card. The card has as input parameters "restaurantName", "restaurantType", "menuItems", "isFavorite" and "onFavoriteToggle" callback function, which allows us to abstract the logic from the component. Additionally, this card returns a Generic Card whose child is the actual restaurant card content.
Note: the background color and the elevation property are being inherited from the Generic Card implementation, so when the Generic Card implementation has these issues fixed, the Restaurant Card should look like the mock version.
Review checklist
whatsnew/whatsnew-pt-PTchangelog.mdwith the change