-
Notifications
You must be signed in to change notification settings - Fork 34
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
feat: ButtonPopover and UserProfilePopover components #2406
Conversation
<> | ||
<Button | ||
{...buttonProps} | ||
isDisabled={buttonProps.isDisabled || isOpen} |
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 this button is disabled when it's open, how can it be closed?
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.
The MUI Popover handles closing (it handles an overlay and clicking anywhere outside of the popover closes it). Kinda like Modal IIRC. Popover has an onClose handler to let you know when it has closed.
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 don't really feel like we really gain anything by disabling this button when the menu is open do we? Feels like we may as well just leave it enabled. Was there a certain issue you ran into that this was solving?
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 functionally, no. This was purely around the presentation, specifically this type of view: https://private-user-images.githubusercontent.com/116028555/382894810-99f3a5be-3e71-47b5-abb6-a648c729e2c6.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MzA3NTA5NDQsIm5iZiI6MTczMDc1MDY0NCwicGF0aCI6Ii8xMTYwMjg1NTUvMzgyODk0ODEwLTk5ZjNhNWJlLTNlNzEtNDdiNS1hYmI2LWE2NDhjNzI5ZTJjNi5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjQxMTA0JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI0MTEwNFQyMDA0MDRaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT02MGRmM2Q3NjI0ZjU5NDViZjcxZDA1ZWM1ZmQ2ODcwMmE2MzU3MmI1Y2UyMWEyOGJkM2E4YzdjZGMyMWFiNDViJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.BArm2CApDOvnKyjNI4FGHz5ZcOokrGuKQZARaZrTaHQ
The UserProfile piece has no border or anything when not hovered. There is no design in Figma that shows how it should change when interactive (hovering/active), so I just took a guess: I figured we'd want something like the disabled view. So what I did here is what you can see in that screenshot.
@@ -37,6 +38,7 @@ const UserProfileIconContainer = styled("div", { | |||
const UserProfileInfoContainer = styled("div")(() => ({ | |||
display: "flex", | |||
flexDirection: "column", | |||
textAlign: "left", |
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.
Doesn't really seem like we need any of these styles. Fairly certain we can remove this styled component entirely and render either a plain div
or a fragment
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.
The textAlign
is definitely needed (the default styles for <button>
have text-align: center
). As for the rest 🤷 ; the UserProfile component itself needs work more generally, I was just making modifications where necessary to get this Popover 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.
No worries. Just figured I'd flag it. If you need the text-align
for a button, I'd probably just pull that button into it's own styled component and apply this there. That way it's a bit more clear what is happening/why this declaration is here.
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 wasn't very clear in my description.
In UserProfilePopover, I was wrapping this component with a MuiButton (here). In that scenario, a text-align
from the button is causing a different layout here in the UserProfile. So this is to reset that / enforce the intended design of this component.
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 extra context, I seen where you were wrapping this in a button. I was trying to say we should style that^ button with textAlign: "left"
directly, rather than applying it here. The reasoning for the text align declaration would be more clear in that scenario, I think
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 my point, though, is that the UserProfile component should always be left aligned regardless of any container it is put in. In that case, it should ensure that it always has the correct alignment no matter what, which is why I'd advocate for having it here at a minimum. Basically, I'm suggesting we insulate this from any consumer doing something silly since this component is exported from Labs by itself as well.
tl;dr: what if someone did <center><UserProfile /></center>
? We'd want the UserProfile component to render with proper alignment no matter what.
children: ReactNode | NullElement; | ||
} & ButtonProps; | ||
|
||
const ButtonPopover = (props: ButtonPopoverProps) => { |
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 we name this something like... ButtonWithPopover
or something similar? Just something that more accurately indicates what this component is/does? The current name leads me to believe that this component is just the popover. But, maybe that's just me. Any thoughts?
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 have zero opinions and am happy to name it whatever. This PR Is mainly to start a conversation (and get design blessing)
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.
Got ya, sounds good. Let's go with adaptable ButtonWithPopover
for now then, if you don't mind :)
|
||
disabled={isOpen} | ||
onClick={openPopover} | ||
variant={isOpen ? "secondary" : "floating"} |
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.
Changing variant
based on state isn't something we do anywhere else in the system. I'd probably recommend just leaving this in the floating
style regardless of it's state
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.
The reason I did this is that the "secondary" variant has a gray background, allowing you to see the outline of the triggering component, while "floating" more closely aligns with the way UserProfile is shown in Figma.
Frankly, in general, this PR is to start a conversation; there's nothing here that's been reviewed by designers.
<> | ||
<MuiButton | ||
{...muiProps} | ||
// aria-controls={ariaControls} |
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 copied this from <Button>
's impl. I wasn't clear if / how many of these types of things should be set on something using <MuiButton>
, so I commented them as a reminder to discuss this. Probably mostly a q for @KevinGhadyani-Okta
DES-6713 feat: smarter column expansion
DES-6714 refactor: alphabetize props feat: add the loading state feat: add more a11y roles feat(odyssey-storybook): add SideNavToggleButton feat(odyssey-storybook): refacor and use new toggle button test: add unit tests for SideNav Merge branch 'bc-jk-sidenav-updates' of github.com:okta/odyssey into bc-jk-sidenav-updates fix: add accessible heading role to sidenav refactor: replace t with useTranslation in imports feat(odyssey-storybook): add translations for toggle button feat(odyssey-storybook): update padding and cleanup footer code feat: add badge to SideNav refactor: updating accessibility roles Merge remote-tracking branch 'origin/main' into bc-jk-sidenav-updates fix: fixes Side nav collapse icon wasn't showing up over the app content fix: fix a11y role violations feat: add overflow scroll to TopNav fix: adjust width of Heading skeleton feat(odyssey-storybook): add custom logo props fix: moves banner above UI Shell # Conflicts: # packages/odyssey-react-mui/src/labs/UiShell/UiShellContent.tsx fix: fixes styling of TopNav slots and responsiveness # Conflicts: # packages/odyssey-react-mui/src/labs/TopNav/TopNav.tsx fix: refactors UI Shell scroll logic into useScrollState fix: minor rename of useScrollState generic feat(odyssey-storybook): more style updates to match Figma feat: adds ability to know if UI Shell is rendered on the page fix: fixes PageTemplate padding for UI Shell mode fix: adds missing clip-path to TopNav shadow fix: fixes border not showing up when scrolling side nav in UI Shell fix: fixes topnav shadow not going over Surface fix: removes unused expandedWidth
DES-6722 fix: update roadmap data fix: update text fix: update roadmap fix: update data
DES-6729 feat(odyssey-react-mui): smaller nav items and focus ring feat(odyssey-react-mui): increase inline padding to make room for button feat(odyssey-react-mui): updated Surface appearance for white backgrounds feat(odyssey-react-mui): build contrastmode into Surface feat(odyssey-react-mui): updated taggle handle color and timing
OKTA-818689 chore(odyssey-react-mui): add namespace
DES-6753 test: fix broken SideNav tests fix: change button role to button component fix: revert broken change
OKTA-824071 feat: adds dran-n-drop feature to the sidenav feat(odyssey-react-mui): smoother transition fix: sidenav props in ui-shell stories
DES-6761 feat(odyssey-react-mui): add custom pagination props to DataView feat(odyssey-react-mui): fix props import path
Closing in favor of the new #2414 |
@@ -225,7 +204,7 @@ const Button = ({ | |||
type={type} | |||
variant={variant} | |||
> | |||
{label} | |||
{children ?? label} |
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 sure why we're adding the children
prop here.
<Box | ||
sx={{ | ||
padding: odysseyDesignTokens.Spacing4, | ||
}} | ||
> |
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.
We should make sure these styles are memoized.
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.
@KevinGhadyani-Okta this is the initial pass and has been closed. Please look at #2414 instead.
OKTA-826088
Summary
A few proposed new (Labs) components:
<Button>
to trigger a MUI<Popover>
to appear with some basic padding<Button>
with a<UserProfile>
as the contents to trigger a MUI<Popover>
to appear with some basic paddingUserProfile needs additional styling, but that's true regardless of this new addition.
Testing & Screenshots
ButtonPopover:
UserProfilePopover:
Practical usage in UIShell-based Admin: