-
Notifications
You must be signed in to change notification settings - Fork 376
feat(Compass): add Compass components #12093
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
|
Preview: https://pf-react-pr-12093.surge.sh A11y report: https://pf-react-pr-12093-a11y.surge.sh |
d78cd03 to
973c50d
Compare
mcoker
left a comment
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.
NIce!! Let a few comments 👍
thatblindgeye
left a comment
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 think I gave enough comments... for now.
Some of this could be followup since it should be pretty easy to implement, just let me know what you think.
| logo?: React.ReactNode; | ||
| /** Content of the navigation area */ | ||
| nav?: React.ReactNode; | ||
| /** Content of the profile area */ | ||
| profile?: React.ReactNode; |
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.
Since these are all optional, we should conditionally render their elements below.
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.
wdyt @mcoker?
Should the logo/nav/profile wrapping divs be present regardless if content is pass to the respective prop? I can't remember if the wrapping divs would effect the spacing or if the nav was vertically aligned independent of the other two divs (or the logo div at least).
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 think if we want to allow someone to pass children to <CompassHeader> and whatever they pass takes up the whole layout, yeah we would conditionally render them. I made logo/nav/profile optional in the core docs assuming you could do this. Though if they pass any one of the three, I think we need to render all 3 for the positioning/centering to work.
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.
Would it be worth an issue in the followup epic for tweaking the styles so that all 3 don't have to be rendered for the positioning to work?
This isn't a blocker by any means, just thinking if we can reduce empty nodes in the DOM it'd be great.
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 user can already pass children directly to header in Compass to achieve this, which was why I wasn't sure if we needed the conditional rendering for this component specifically since we'd want all 3 divs if any one div was passed.
| <FlexItem grow={{ default: 'grow' }}>{title}</FlexItem> | ||
| <FlexItem>{toolbar}</FlexItem> |
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.
Can wew conditioanlly render these flex items depending on whether the applicable prop is passed
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'll update the toolbar flex item to conditionally render since its an empty div otherwise, but I think we want to let the title flex item always render so if only toolbar content is passed it will still be pushed right (since this is the more opinionated rendering logic). If a user wanted a left-aligned toolbar, they could get by passing that to the title, or use children directly.
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'm wondering if we should have a __title and __toolbar element instead of including the flex layout? I could then make the toolbar element always be on the right regardless of whether there is a title element or not.
You can also do this in the existing flex layout tho by doing this
| <FlexItem grow={{ default: 'grow' }}>{title}</FlexItem> | |
| <FlexItem>{toolbar}</FlexItem> | |
| <FlexItem grow={{ default: 'grow' }}>{title}</FlexItem> | |
| <FlexItem align={{ default: 'alightRight' }}>{toolbar}</FlexItem> |
| /** Content placed at the top of the layout */ | ||
| header?: React.ReactNode; |
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.
For these "area" props (header, footer, main, side panels), would we want to have wrapper containers introduced (CompassFooter, CompassMain, etc) that would be suggested to be passed in?
Or do we just want people to pass whatever they want into them, using the other Compass components in this PR when necessary?
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 think we want to leave these wrapper containers to the Compass since that controls the actual layout, and allows a user some flexibility if they want the layout but don't want the specific structure imposed by the typical child components. Those components (CompassHeader, CompassMessageBar, CompassContent, etc) are more opinionated/helper components to help achieve the same PoC style.
| /** Content placed at the start of the layout */ | ||
| sidebarStart?: React.ReactNode; | ||
| /** Flag indicating if the start sidebar is expanded */ | ||
| isSidebarStartExpanded?: boolean; |
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.
Might be missing something, but setting these expanded props to false doesn't do anything in the examples added. It removes the expanded class, but the content is still visible.
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.
At least one design file showed these blocks sliding in and out of the layout like drawers, so Katie added support for it via these props & .pf-m-expanded, but we haven't implemented any styles yet.
| isFilled?: boolean; | ||
| /** Enables subtab tab styling */ | ||
| isSubtab?: boolean; | ||
| /** Enables horizontal nav tab styling */ |
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.
| /** Enables horizontal nav tab styling */ | |
| /** @beta Enables horizontal nav tab styling */ |
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.
This may be a bit of an overlap with another issue dedicated to adding the nav styling to Tabs, I forgot we included this locally to test things out.
I'll leave it in for now, but @dlabaj feel free to override or leave in this flag as part of #12080, since tests and maybe an example would be good to add in Tabs still.
packages/react-core/src/components/Compass/examples/CompassDemo.tsx
Outdated
Show resolved
Hide resolved
wise-king-sullyman
left a comment
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.
Couple small comments on the example/demo but nothing I'd block over that wasn't already covered by others
| sidebarEnd={sidebarEndContent} | ||
| footer={footerContent} | ||
| backgroundSrcDark="https://i.imgur.com/km6oyPo.jpeg" | ||
| /> |
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.
Not something I would block over, but I think we should probably add a light background image here otherwise people will complain about the demo not working in light mode.
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.
Yeah I'm debating whether we get more static links or add the images as assets for the demo, or leave them out entirely in favor of using them in the full fledged org demos. I had included it initially just testing the prop.
Probably will leave them out for the basic inline example.
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've updated the demo to use the same image as BackgroundImage. Wdyt? (cc @mcoker)
Should we ask design for some more PF gradient colors for light and dark theme as well?
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 agree we should have a background for the light demo. For the core demos, I've included
- Light and dark background images for the compass wrapper
- Using a single background image for the hero element
- Only passing a gradient to hero in dark, and letting the normal "glass" background show in light since that was in one of the designs
We could ask for a light gradient and light background for the hero element, then we would have light and dark customizations for everything. IMO design can give us that feedback when they see the demos unless you want to make a point to ask them?
| sidebarEnd={sidebarEndContent} | ||
| footer={footerContent} | ||
| backgroundSrcDark="https://i.imgur.com/km6oyPo.jpeg" | ||
| /> |
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.
Same note here
mcoker
left a comment
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.
LGTM!
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.
This all LGTM. Some things that maybe we could add to the followup epic:
- Touched on it in a response above, but seeing if we could tweak the CSS so that we don't have to render empty elements for positioning/etc to work correctly. Basically anywhere we have an optional prop in React where that prop doesn't dictate the rendering of a wrapper container. Not a blocker if we just need to keep them, though; like I said, would be nice if we can just prevent empty stuff from being rendered if they don't need to be there.
- More depending on if we could do the above, but if we need to keep these empty elements then maybe a followup to add some tests that check "[element] renders when prop isn't passed". Would need to add some
[element]Propsprops to spread, "mainProps", "headerProps", etc. - Going back through to ensure we aren't hardcoding classes in the test files ("Renders logo with pf-v6-c-compass__logo class" was one example
What: Closes #12078
Awaiting styles.
Assisted sparsely in refactoring/autocomplete by Cursor AI. Tests were assisted more comprehensively by Cursor AI.