-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
[DEV-17234] Update marketplace menu item #21456
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
Conversation
@sgiehl can you please provide any feedback you may have on the approach? Is it ok to leave it like this or do we need to change it substantially (if so, how)? |
e88fc15
to
d0b14f2
Compare
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.
Had a rough look through the code. The approach looks fine to me that way.
Left a couple of comments for things that came to my mind when looking through the changes...
49fda80
to
42a059e
Compare
42a059e
to
3b2863d
Compare
2c358b1
to
112d069
Compare
PM is ok with the menu items being removed from the quick access menu. Keyboard access to the new rich menu button works.
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.
Confirmed with PM that the quick access items for Marketplace are OK to be removed as long as the new rich button in menu nav is accessible using a keyboard.
@@ -48,6 +48,7 @@ public function test_buildWidgetMetadata_ShouldGenerateMetadata() | |||
'order' => 99, | |||
'icon' => '', | |||
'help' => '', | |||
'widget' => null, |
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.
Probably a good idea to test this with an actual value at least once.
As you are missing a test for this logic:
'widget' => $category->getWidget() ?: null,
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.
Yep, I can probably update one of the system tests where it returns the API response in XML format for comparison.
Otherwise the UI tests for the menu already cover the visual component override depending on this working.
if (category.widget && category.widget.indexOf('.') > 0) { | ||
const [widgetPlugin, widgetComponent] = category.widget.split('.'); |
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.
if (category.widget && category.widget.indexOf('.') > 0) { | |
const [widgetPlugin, widgetComponent] = category.widget.split('.'); | |
const widgetParts = category.widget.split('.'); | |
if (category.widget && widgetParts.length === 2) { | |
const [widgetPlugin, widgetComponent] = widgetParts; |
Just to prevent bugs/issues later when there are category.widget
values of things like a.b.c
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 can add a limit to the split function so it always produces two parts from the first two, or we use splat to catch all the remaining parts into the component.. or I can add a check to the setWidget
call that would throw on invalid format inputs... basically I don't think it should be dealt with here in this way, but happy to discuss. It's basically a matter "if someone provides incompatible format widget notation, it won't work for them" and them is mostly us.
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.
Maybe in the backend is better setWidget
can be a run time error at least and stop any headaches going forward. A bit of defensive programming.
Otherwise it could be a value object with two parts plugin
and component
and a __toString() method that concats them in the correct format.
I'm still a bit hesitant to approve this, but I did test it locally and it's all good. Maybe @sgiehl you wouldn't mind taking a look as you looked at the approach earlier in the PR |
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.
Overall looks good to me and works as expected. Left a minor comment for a possible improvement. Otherwise this looks good to merge.
@@ -93,14 +100,21 @@ | |||
</ul> | |||
<ul | |||
id="mobile-left-menu" | |||
class="sidenav hide-on-large-only" | |||
class="sidenav sidenav--reporting-menu-mobile hide-on-large-only" |
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.
Any reason for adding a new class name here instead of using the existing ones or maybe the id? Just wondering why the already available attributes shouldn't be enough to select the element in CSS. If the available classes aren't unique enough you could simply use the class reportingMenu
of the surrounding div.
Also the double-dash class name looks really ugly. I know we have a couple other places where that is used, but imho we should maybe try to get rid of them instead of adding new ones.
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.
Thanks for the comment @sgiehl!
Probably didn't need the new class, that's true. There's so many different ways of targeting elements in CSS. I don't think using the ID is the right way and I thought the sidenav wasn't unique to this element, and a combination of e.g. .sidenav.hide-on-large-only
is also not the prettiest.
The --
double dash is a modifier syntax from the BEM methodology. Although there might be a couple of similar uses in other places, it's true it wasn't necessary here either.
We should perhaps standardise how we do CSS and front-end naming in general and then we can have a common and shared approach to new additions, otherwise it'll be a mix of things.
…ar (#21456) * Fix CS * Fix typo in UI demo example * Add styling and UI demo example for outline button (with reverse bg on hover) * Remove premium features widget * Allow category to have a custom widget for the reporting menu * Implement marketplace rich menu button * Remove surplus category config * Build vue files * Update unit tests with an empty category widget prop * Update system test expected files * Add type hints * Update UI test screenshots * Update expected API response xml * Partially revert "Remove premium features widget" This reverts commit 5f37b02. We are not reverting the removal of the subcategory. * built vue files * Restore Paid Plugins widget in system test expected files Partially reverts commit c351ec9. * Update expected test files * Use data attribute instead of CSS class * Add tabindex * Build vue files * built vue files * Let category load when there's exactly one subcategory or multiple subcategories and an override widget * Add support for keyboard submit * Build vue files * Update quick access search UI test screenshot PM is ok with the menu items being removed from the quick access menu. Keyboard access to the new rich menu button works. * Update built vue files --------- Co-authored-by: michalkleiner <michalkleiner@users.noreply.github.com>
…ar (4 Backport) (#21512) * [DEV-17234] Add more visually striking marketplace menu item in sidebar (#21456) * Fix CS * Fix typo in UI demo example * Add styling and UI demo example for outline button (with reverse bg on hover) * Remove premium features widget * Allow category to have a custom widget for the reporting menu * Implement marketplace rich menu button * Remove surplus category config * Build vue files * Update unit tests with an empty category widget prop * Update system test expected files * Add type hints * Update UI test screenshots * Update expected API response xml * Partially revert "Remove premium features widget" This reverts commit 5f37b02. We are not reverting the removal of the subcategory. * built vue files * Restore Paid Plugins widget in system test expected files Partially reverts commit c351ec9. * Update expected test files * Use data attribute instead of CSS class * Add tabindex * Build vue files * built vue files * Let category load when there's exactly one subcategory or multiple subcategories and an override widget * Add support for keyboard submit * Build vue files * Update quick access search UI test screenshot PM is ok with the menu items being removed from the quick access menu. Keyboard access to the new rich menu button works. * Update built vue files --------- Co-authored-by: michalkleiner <michalkleiner@users.noreply.github.com> * Update JS for 4.x * Update screenshot tests * Undo tests didn't need to change * Undo tests didn't need to change --------- Co-authored-by: Michal Kleiner <michal@innocraft.com> Co-authored-by: michalkleiner <michalkleiner@users.noreply.github.com>
Description:
Ref. DEV-17234
@sgiehl can you check the approach here? It's based on Marc's investigation into how this might be possible to achieve and it seems to be working ok.
The approach is to allow any category to pass a vue component widget string that gets translated into a component when the menu is constructed.
The click event is reused from the category so the target widget loads in the righthand side area as expected.
I've also added the outline link to the UI demo view.
Remaining to do:
Review