Skip to content

Conversation

@kmcfaul
Copy link
Contributor

@kmcfaul kmcfaul commented Oct 23, 2025

What: Closes #12078

Awaiting styles.

Assisted sparsely in refactoring/autocomplete by Cursor AI. Tests were assisted more comprehensively by Cursor AI.

@kmcfaul kmcfaul marked this pull request as draft October 23, 2025 17:54
@patternfly-build
Copy link
Collaborator

patternfly-build commented Oct 23, 2025

@kmcfaul kmcfaul force-pushed the compass branch 2 times, most recently from d78cd03 to 973c50d Compare October 28, 2025 23:37
@kmcfaul kmcfaul linked an issue Oct 29, 2025 that may be closed by this pull request
@kmcfaul kmcfaul marked this pull request as ready for review October 29, 2025 16:06
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.

NIce!! Let a few comments 👍

Copy link
Contributor

@thatblindgeye thatblindgeye 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 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.

Comment on lines +6 to +10
logo?: React.ReactNode;
/** Content of the navigation area */
nav?: React.ReactNode;
/** Content of the profile area */
profile?: 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.

Since these are all optional, we should conditionally render their elements below.

Copy link
Contributor Author

@kmcfaul kmcfaul Oct 29, 2025

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).

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 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.

Copy link
Contributor

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.

Copy link
Contributor Author

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.

Comment on lines 27 to 28
<FlexItem grow={{ default: 'grow' }}>{title}</FlexItem>
<FlexItem>{toolbar}</FlexItem>
Copy link
Contributor

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

Copy link
Contributor Author

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.

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 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

Suggested change
<FlexItem grow={{ default: 'grow' }}>{title}</FlexItem>
<FlexItem>{toolbar}</FlexItem>
<FlexItem grow={{ default: 'grow' }}>{title}</FlexItem>
<FlexItem align={{ default: 'alightRight' }}>{toolbar}</FlexItem>

Comment on lines +11 to +12
/** Content placed at the top of the layout */
header?: 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.

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?

Copy link
Contributor Author

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;
Copy link
Contributor

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.

Copy link
Contributor

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 */
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
/** Enables horizontal nav tab styling */
/** @beta Enables horizontal nav tab styling */

Copy link
Contributor Author

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.

@wise-king-sullyman wise-king-sullyman self-requested a review October 29, 2025 19:18
Copy link
Collaborator

@wise-king-sullyman wise-king-sullyman left a 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"
/>
Copy link
Collaborator

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.

Copy link
Contributor Author

@kmcfaul kmcfaul Oct 29, 2025

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.

Copy link
Contributor Author

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?

Copy link
Contributor

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"
/>
Copy link
Collaborator

Choose a reason for hiding this comment

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

Same note here

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.

LGTM!

Copy link
Contributor

@thatblindgeye thatblindgeye left a 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]Props props 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

@wise-king-sullyman wise-king-sullyman merged commit ff397d8 into patternfly:main Oct 30, 2025
13 checks passed
@kmcfaul kmcfaul linked an issue Nov 3, 2025 that may be closed by this pull request
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Draft a react demo for testing Compass - new layout components Glass styling

6 participants