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

Vertical navbar #5854

Merged
merged 30 commits into from
Nov 6, 2019
Merged

Vertical navbar #5854

merged 30 commits into from
Nov 6, 2019

Conversation

fhlavac
Copy link
Contributor

@fhlavac fhlavac commented Jul 23, 2019

Task

#5759

@Hyperkid123 @martinpovolny @epwinchell

  • Rewritten structure generation - made it recursive and moved it to navbar.rb
  • Rewritten and divided React main_menu component into level components
  • Created recursive PropTypes
  • Created main-menu tests

vertical-navbar

fixes https://bugzilla.redhat.com/show_bug.cgi?id=1734661

@Hyperkid123
Copy link
Contributor

Adding a bit of context.

Right now it still uses the same logic as current navigation. This PR changes migrates the haml layout to React and adds a new function that generates JSON fro which the menu is rendered.

In future PR we will move all the show/hide, click/hover and any other logic to the react component. Currently that is handled via pf JS which is triggering these state changes based on css classes (not id or any other unique identifiers)

I know that @epwinchell has some requests to change the current behavior. We would like to introduce them once we start moving the logic to React component. @epwinchell if you could create GH issue with the changes you would like to see that would be great.

0: props => <TopLevel level={level} {...props} />,
1: props => <SecondLevel level={level} {...props} />,
2: props => <ThirdLevel level={level} {...props} />,
})[level];
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we should add a fallback component if somebody passes level value other than 0 - 3

const getLevelComponent = level => ({
  0: props => <TopLevel level={level} {...props} />,
  1: props => <SecondLevel level={level} {...props} />,
  2: props => <ThirdLevel level={level} {...props} />,
})[level] ||  props => <ThirdLevel level={level} {...props} />;

This will always return ThirdLevel component if you gave the function any level that it does not cover.

items,
level,
}) => (
<li className={`list-group-item ${items.length > 0 && 'tertiary-nav-item-pf'}`} data-target={`#menu-${id}`}>
Copy link
Contributor

Choose a reason for hiding this comment

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

This will add false to className if the condition is not met. We don't want that.

@martinpovolny martinpovolny changed the title Vertical navbar [WIP] Vertical navbar Jul 23, 2019
</div>
<ul className="list-group">
{
items.map(props => <MenuItem key={props.id} level={level + 1} {...props} />)
Copy link
Contributor

Choose a reason for hiding this comment

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

Put this on single line please.

@martinpovolny
Copy link
Member

Marking this as "WIP" as we do not want it merged (even if it was finished) until the release is out.

@@ -15,7 +15,7 @@
%li.dropdown{"open" => "!hideDrawer"}
%a{:class => "nav-item-iconic drawer-pf-trigger-icon", :title => "{{vm.notificationsIndicatorTooltip}}", "ng-click" => "vm.toggleNotificationsList()"}
%span.fa.fa-bell
%span{"ng-class" => "{'badge badge-pf-bordered': vm.newNotifications}"}
%span{"ng-class" => "{'badge badge-pf-bordered': vm.newNotifications}"}
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 think this file should be changed 😉

@Hyperkid123
Copy link
Contributor

@miq-bot add_label react
@miq-bot add_label hammer/no

@epwinchell
Copy link
Contributor

@miq-bot add_reviewer @epwinchell

@miq-bot miq-bot requested a review from epwinchell July 29, 2019 18:00
Copy link
Contributor

@epwinchell epwinchell left a comment

Choose a reason for hiding this comment

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

Works great

@epwinchell
Copy link
Contributor

@fhlavac Please rebase

@epwinchell
Copy link
Contributor

if you could create GH issue with the changes you would like to see that would be great.

https://bugzilla.redhat.com/show_bug.cgi?id=1734181

Copy link
Contributor

@Hyperkid123 Hyperkid123 left a comment

Choose a reason for hiding this comment

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

Looks good. @martinpovolny i think you can merge this once the release is out. We will continue with next PR that will extract the logic from PF3. We will have to re do the top Nav too because its controlled by the same PF JS code.

@martinpovolny
Copy link
Member

Ok, @fhlavac : please un"WIP" the PR.

@epwinchell : good to go?

@himdel
Copy link
Contributor

himdel commented Jul 31, 2019

Is this new menu expected to support all the existing features?
(Except for clicking on sections.)

Specifically, I'm not seeing any code dealing with:

  • calling miqCheckForChanges before leaving a form
  • opening links in a new window
  • opening modals (via sendDataWithRx)

@himdel
Copy link
Contributor

himdel commented Jul 31, 2019

(This should really not be ignoring anything from link_params, but it only reads the href it seems.)

=> not ready yet IMO

@martinpovolny
Copy link
Member

@himdel : I sort of expected something like that ;-)

Can we somehow capture the functionality that you pointed out in some tests? Sounds to me like 3 pretty important concepts and all the tests are green.

@himdel
Copy link
Contributor

himdel commented Jul 31, 2019

Well, link params provided the whole %a attributes hash in the view. So, it's probably the only place to look at, but also painful to test.

Though, since we're moving to react, a new snapshot test could cover this.

@epwinchell
Copy link
Contributor

@martinpovolny yes, reviewed/approved

@fhlavac fhlavac force-pushed the react_menubar branch 2 times, most recently from 4c12d7e to a8df32e Compare August 27, 2019 08:58
@fhlavac
Copy link
Contributor Author

fhlavac commented Aug 27, 2019

@martinpovolny @himdel

  • Added support for missing types from link_params - "modal", "big_iframe" and "new_window".
    (It would be nice to have data where these types occur to be able to really test it. I verified the functionality only by changing some items with "default" type to the other types mentioned.)

  • Fixed calling miqCheckForChanges before leaving a form.

@fhlavac fhlavac changed the title [WIP] Vertical navbar Vertical navbar Aug 27, 2019
@skateman
Copy link
Member

skateman commented Nov 6, 2019

The CSS can be simplified, the JSON conversion can be refactored, but in a future PR, I'm good with this. Clicked through the UI a little and it all worked, even the custom menu.

Copy link
Member

@skateman skateman left a comment

Choose a reason for hiding this comment

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

The Seal of Approval

@himdel
Copy link
Contributor

himdel commented Nov 6, 2019

Confirming custom menus are working :)

But now everything has an id, not only menu items.
@fhlavac can you please make sure only menu items get ids? Or change the section ids to use the menu_section_ prefix instead of menu_item_?

@miq-bot
Copy link
Member

miq-bot commented Nov 6, 2019

Checked commits fhlavac/manageiq-ui-classic@24e56b0~...4eb3f7d with ruby 2.4.6, rubocop 0.69.0, haml-lint 0.20.0, and yamllint 1.10.0
1 file checked, 0 offenses detected
Everything looks fine. ⭐

@fhlavac
Copy link
Contributor Author

fhlavac commented Nov 6, 2019

Update:

  • items have menu_item_ prefixes
  • sections have menu_section_ prefixes
  • removed redundant data-target at top and second level

@himdel
Copy link
Contributor

himdel commented Nov 6, 2019

Merging when green :)

@skateman
Copy link
Member

skateman commented Nov 6, 2019

ssh, it's green 😉

@himdel himdel merged commit e0131a4 into ManageIQ:master Nov 6, 2019
@himdel himdel added this to the Sprint 124 Ending Nov 11, 2019 milestone Nov 6, 2019
require('jquery.hotkeys');

// all of patternfly js except for vertical navigation (patternfly-functions-vertical-nav.js)
Copy link
Contributor

Choose a reason for hiding this comment

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

so, this bit didn't really work,
because require('angular-patternfly') requires the whole thing anyway.

Fixing in #6449,
and removing the call to setupVerticalNavigation which no longer works without patternfly-functions-vertical-nav.js.

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

Successfully merging this pull request may close these issues.

7 participants