Skip to content

Conversation

@jschuler
Copy link
Collaborator

@jschuler jschuler commented May 8, 2020

What: Closes #4106

This PR updates the page demos to use the new PageHeaderTools/PageHeaderToolsGroup/PageHeaderToolsItem components

https://patternfly-react-pr-4223.surge.sh/documentation/react/demos/pagelayout

Breaking changes

PageHeader: avatar prop was removed. Add the avatar to the PageHeaderTools component instead (which is passed into PageHeader via the headerTools prop.
PageHeader: toolbar prop was removed. Use the headerTools prop instead. Also, if you previously used the Toolbar, ToolbarGroup, or ToolbarItem components for the header, replace them with the PageHeaderTools, PageHeaderToolsGroup, and PageHeaderToolsItem components.

@patternfly-build
Copy link
Collaborator

patternfly-build commented May 8, 2020

Copy link
Contributor

@redallen redallen 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, just need some notes

section: components
cssPrefix: 'pf-c-page'
typescript: true
propComponents: ['Page', 'PageHeader', 'PageSidebar', 'PageSection']
Copy link
Contributor

Choose a reason for hiding this comment

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

Should the new Components be listed here so their props are included in the docs?

Copy link
Member

@dlabrecq dlabrecq left a comment

Choose a reason for hiding this comment

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

LGTM

className={css(
styles.pageHeaderToolsGroup,
className,
hiddenOnLg && styles.modifiers.mobile,
Copy link
Contributor

Choose a reason for hiding this comment

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

If we're going to structure this so that we offer header toolbar groups and items that require the user specify visibleOnLg for items that are only visible on desktop, hiddenOnSm for items that are hidden on mobile, etc, then I wonder if we should drop the current modifiers and use a hidden/visible mixin that would give us a set of styles that allow a user to specify pf-m-hidden[-on-{breakpoint}] and pf-m-visible[-on-{breakpoint}] on any header-tools-group or header-tools-item. In this PR, users can only specify hiddenOnLg , visibleOnLg, and hiddenOnSm.

Then users will have full control over hiding/showing things at any breakpoint. The downside to the current approach (whether we include the mixin or not) is that the responsibility is on the user to hide/show header toolbar items appropriately. The alternative to that would be to have something like 3 props on the header tools component, mobileDropdown, desktopActions, and userMenu or something like that, and we put the contents of those props in the appropriate classes and control the mobile, desktop, and user menu breakpoints where that content is hidden/shown.

The former seems like the better approach, but could lead to inconsistency in implementation. @mcarrano wdyt? If we're OK allowing users to hide/show any header toolbar items/groups at any breakpoint, but we show the proper way to do it in the demos and could have a masthead/header design guideline that goes into more detail, I'd like to drop the existing classes and add the full hidden/visible breakpoint classes to header toolbar groups and items.

We could keep the existing classes and add the hidden/visible classes on top, but that seems like it might be confusing to have both, and the prop names that enable the current classes seem like they would overlap.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yes, I was going back and forth with the prop names, initially I named them something similar to your mentioned alternative before landing on this (as it also seemed familiar with what we have in other components).
I guess if we wanted to we could streamline this even more and provide a way for users to define specific things and we can lay it out for them:

<PageHeaderTools 
   mobileDropdown={<Dropdown />}
   desktopActions={
      { component: <NotificationBadge />, isSelected: false }
      { component: <Button><CogIcon /></Button>, isSelected: true }
   }
   userDropdown={
      <Dropdown />
   }
   avatar={<Avatar />}
>
   Other components here that should come before?
</PageHeaderTools>

Maybe this for ease-of-use, but still allow users to use the component without those convenience props and define the content themselves using visibility mixins?

Copy link
Contributor

Choose a reason for hiding this comment

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

Looking at the way it's done in master now, it looks like we import the accessibility utility classes and it's up to users to apply hidden/visible classes on their own. It seems logical then to bake this hidden/visible behavior into the page header tools, and give users the ability to hide/show header elements at any breakpoint.

* will render
* <button class="pf-m-plain pf-m-selected">Hello</button>
*/
export const PageHeaderToolsItem: React.FunctionComponent<PageHeaderToolsItemProps> = ({
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm curious how this component works. I think it would be more consistent if we had a .pf-c-page__header-tools-item class that you could apply hidden/visible to. I'm assuming that would still allow us to apply .pf-m-selected to a <Button> used in .pf-c-page__header-tools-item if it has the isSelected prop?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

So the problem is, in HTML you can just add the pf-m-selected class to a button anywhere. If you wanted to do this in react you'd have to manually add this class name yourself i.e.

<PageHeaderTools>
  <PageHeaderToolsGroup>
      <Button className="pf-m-selected">
          <CogIcon />
      </Button>
  </PageHeaderToolsGroup>
</PageHeaderTools>

because the selected modifier is not a prop we have available for Buttons, the class is defined in the context of page.

Wrapping the <Button> component in <PageHeaderToolsItem> basically allows me to pass the pf-m-selected class or any other potential modifier down to the child component.

Copy link
Contributor

@mcoker mcoker left a comment

Choose a reason for hiding this comment

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

This looks great, @jschuler! I left a few comments and created a follow up core issue to fix an alignment issue I'm seeing with one of the buttons in the header patternfly/patternfly#3086. Though how we fix that depends on what we decide with the comments I left, so I'll hold off on addressing #3086 for the time being.

@mcarrano
Copy link
Member

mcarrano commented May 11, 2020

@jschuler I realize that the goal of this PR is not to fully implement the intended design updates for the masthead, but here is a Marvel deck that shows where we want to get to for reference: https://marvelapp.com/5cjajdg/screen/63256946 Getting the demo as close as possible to this would be great. Note the the Notification icon never hides.

@jschuler
Copy link
Collaborator Author

@mcarrano thanks for that, I'll update the demo to reflect this layout as much as possible.

@mcarrano @mcoker and @mceledonia and I met this morning and decided that core will make some changes. Core will remove the pf-m-mobile, pf-m-user, and pf-m-icons classes, and instead bring in the breakpoint modifier classes.
Core will also create a pf-c-page__header-tools-item class.

Once these changes are in the core v4 branch, we'll bring it into react and then I'll update this PR. So it'll be on hold until then!

@mcoker
Copy link
Contributor

mcoker commented May 11, 2020

@jschuler patternfly/patternfly#3091 was merged.

  • Removed .pf-m-[icon/mobile/user]
  • Adds .pf-c-page__header-tools-item (as a child of .pf-c-page__header-tools-group)
    • .pf-c-page_-header-tools-group is still required for any .pf-c-page__header-tools-item
  • Adds .pf-m-hidden[-on-{breakpoint}] and .pf-m-visible[-on-{breakpoint}] that can be applied to __header-tools-[item/group]

@redallen
Copy link
Contributor

Depends on #4243

/** Content rendered in page header tools item. If you need the selected class, use the render prop instead */
children?: React.ReactNode;
/** If you need the selected class, use this render prop instead of children */
render?: (props: InjectedPageHeaderToolsItemProps) => React.ReactNode;
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

opened issue in core so this hopefully won't be necessary to get the selected class
patternfly/patternfly#3108

Copy link
Contributor

Choose a reason for hiding this comment

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

We haven't really used an API like this before, but I like it and I think it satisfies the documentation part.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yes, I remembered there was some controversy about using cloneElement so render prop puts the resposibility of adding the class back to the user. anyways, this render prop will be short-lived once the mentioned core PR is available :)

Copy link
Contributor

@redallen redallen left a comment

Choose a reason for hiding this comment

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

I think after RC1 we can come back and clean up the render API. One it passes CI this LGTM.

/** Content rendered in page header tools item. If you need the selected class, use the render prop instead */
children?: React.ReactNode;
/** If you need the selected class, use this render prop instead of children */
render?: (props: InjectedPageHeaderToolsItemProps) => React.ReactNode;
Copy link
Contributor

Choose a reason for hiding this comment

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

We haven't really used an API like this before, but I like it and I think it satisfies the documentation part.

@jschuler jschuler removed the on hold label May 13, 2020
Copy link
Contributor

@redallen redallen left a comment

Choose a reason for hiding this comment

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

LGTM! Thanks @jschuler !

@tlabaj tlabaj added the Breaking change 💥 this change requires a major release and has API changes. label May 13, 2020
<div
className={css(
styles.pageHeaderToolsGroup,
breakpointMods && formatBreakpointMods(breakpointMods, styles),
Copy link
Contributor

Choose a reason for hiding this comment

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

I opened an issue agains the page header. formatBreakpointMods function does not work for the 2xl breakpoint.

@mcoker
Copy link
Contributor

mcoker commented May 13, 2020

This LGTM, my only comments are that the notification bell should be in a header-tools-item element, and that the cog shouldn't be selected. We can add the selected state as an example with either a drawer or notification drawer demo where a header tools button toggles a drawer.

Copy link
Member

@mcarrano mcarrano left a comment

Choose a reason for hiding this comment

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

This is looking good @jschuler . I just had a couple of requests to try and get this closer to the intended design.

  • At the medium breakpoint the avatar should hide and the user dropdown just displays the user name as shown here:

Screen Shot 2020-05-13 at 3 33 30 PM

  • At the small breakpoint, the user menu should collapse entirely into the kebob as shown here:

Screen Shot 2020-05-13 at 3 37 47 PM

The way it is now, the user menu is not accessible when only the avatar is present.

Also, I would remove the selected state from the gear icon. Ideally each of those icons would have a hover which is same as the selected state you are showing. Let me know if you have questions. I would be glad to walk through this with you.

@codecov-io
Copy link

Codecov Report

Merging #4223 into v4 will decrease coverage by 2.49%.
The diff coverage is 42.88%.

Impacted file tree graph

@@            Coverage Diff             @@
##               v4    #4223      +/-   ##
==========================================
- Coverage   57.85%   55.36%   -2.50%     
==========================================
  Files         391      428      +37     
  Lines        5979     7077    +1098     
  Branches     2354     2612     +258     
==========================================
+ Hits         3459     3918     +459     
- Misses       2064     2666     +602     
- Partials      456      493      +37     
Flag Coverage Δ
#patternfly4 55.36% <42.88%> (-2.50%) ⬇️
Impacted Files Coverage Δ
...ages/react-core/src/components/Page/PageHeader.tsx 72.72% <0.00%> (+6.06%) ⬆️
packages/react-core/src/components/Tabs/Tab.tsx 100.00% <ø> (ø)
...kages/react-core/src/components/Tabs/TabButton.tsx 83.33% <ø> (ø)
packages/react-core/src/helpers/util.ts 46.66% <ø> (ø)
...mponents/Table/utils/decorators/compoundExpand.tsx 90.00% <ø> (ø)
...-table/src/components/Table/utils/transformers.tsx 100.00% <ø> (ø)
...ackages/react-topology/src/utils/useCallbackRef.ts 0.00% <0.00%> (ø)
packages/react-topology/src/elements/BaseEdge.ts 1.61% <1.61%> (ø)
packages/react-topology/src/utils/svg-utils.ts 2.56% <2.56%> (ø)
packages/react-topology/src/utils/useHover.ts 3.03% <3.03%> (ø)
... and 94 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d671a80...ee09981. Read the comment docs.

@mcoker
Copy link
Contributor

mcoker commented May 14, 2020

@jschuler looks like we lost the header tools in the card view demo - https://patternfly-react-pr-4223.surge.sh/documentation/react/demos/cardview/basic. Otherwise LGTM!

@jschuler
Copy link
Collaborator Author

@mcoker thanks, I can add those in a followup PR

Copy link
Member

@mcarrano mcarrano left a comment

Choose a reason for hiding this comment

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

Thanks for the latest set of updates @jschuler . This looks good now.

@redallen redallen requested a review from tlabaj May 14, 2020 16:28
Copy link
Contributor

@tlabaj tlabaj left a comment

Choose a reason for hiding this comment

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

Thanks for the updates. Looks good.

@redallen
Copy link
Contributor

@jschuler Fix conflicts and we can merge!

@redallen redallen merged commit 3a7ae11 into patternfly:v4 May 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Breaking change 💥 this change requires a major release and has API changes.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Toolbar layout needs to be removed from the Page component (on the black header) and on all demos that use the Page component.

9 participants