-
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: adds a generic top nav component #2296
Conversation
@@ -0,0 +1,45 @@ | |||
/*! |
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 if we already have these icons somewhere.
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 icons should be in Figma. we then run a script to pull them into Odyssey.
If they're not in Figma, then when we run the "pull down new icons" script, it will remove this one.
There are other scripts we run to process the icons too. Then we make a PR and get those up.
@@ -26,6 +26,8 @@ export * from "./ArrowUnsorted"; | |||
export * from "./ArrowUp"; | |||
export * from "./ArrowUpperLeft"; | |||
export * from "./ArrowUpperRight"; | |||
export * from "./Aura"; | |||
export * from "./AuraWordmark"; |
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.
plmk if this exists already or if I should combine these 2 into a single svg/icon.
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.
Don't think either of these exist. Does it make sense to create a component like OktaLogo
that can render either one? Maybe it takes a variant
prop for logoOnly
and logoAndWordMark
or something?
const LogoWordmarkStyles = useMemo( | ||
() => ({ | ||
width: "55px", | ||
height: "20px", | ||
paddingLeft: odysseyDesignTokens.Spacing2, | ||
}), | ||
[odysseyDesignTokens], | ||
); |
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 see if we could get these values lined up with design tokens somehow.
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.
Couldn't find any tokens that might work for these props
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.
@ganeshsomasundaram-okta We should use Spacing9
for the width. And we probably don't need to set a height 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.
Also curious why it needs padding here. I'd think the containing element would provide any necessary padding
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 @bryancunningham-okta I'll use the Spacing9, it is slightly smaller than the figma spec but it should be close enough. Also, there is a padding/gap between the aura and the workmark in the design. I don't have a container around the aura/workmark.
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.
Ah, got ya. Can we use margin instead then? Makes it more clear what the intention is. And use the logical css property
marginInlineStart: odysseyDesignTokens.Spacing2
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.
removed the logo for now to unlock this PR. We are waiting from the design team to confirm where the logo would go (between top-nav and side-nav). There are some inconsistencies on the logo behavior/location between enduser & admin apps that design team needs to consolidate.
/** | ||
* Pass in an additional componnet like Button that will displayed after the nav link items | ||
*/ | ||
AdditionalNavItemComponent?: ReactElement; |
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 is really open-ended. I don't understand why it's here either. Is this part of the design where we want clickable nav items to have clickable items inside them?
For accessibility reasons, that's typically a big no-no.
Also this:
/** | |
* Pass in an additional componnet like Button that will displayed after the nav link items | |
*/ | |
AdditionalNavItemComponent?: ReactElement; | |
/** | |
* Pass in an additional component like `Button` that will displayed after the nav link items. | |
*/ | |
AdditionalNavItemComponent?: ReactElement; |
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.
Yes, there's a use case where the workflows UI has an additional button at the end. I have this prop to cover that use case.
const TopNavListItemContainer = styled("li", { | ||
shouldForwardProp: (prop) => | ||
prop !== "odysseyDesignTokens" && prop !== "isDisabled", | ||
})<{ | ||
odysseyDesignTokens: DesignTokens; | ||
isDisabled?: boolean; | ||
}>(({ odysseyDesignTokens, isDisabled }) => ({ | ||
display: "flex", | ||
alignItems: "center", | ||
cursor: isDisabled ? "default" : "pointer", | ||
pointerEvents: isDisabled ? "none" : "auto", | ||
"& a": { | ||
display: "flex", | ||
alignItems: "center", | ||
padding: `${odysseyDesignTokens.Spacing2} ${odysseyDesignTokens.Spacing4}`, | ||
color: `${odysseyDesignTokens.TypographyColorHeading} !important`, | ||
}, | ||
"& a:hover": { | ||
textDecoration: "none", | ||
backgroundColor: !isDisabled ? odysseyDesignTokens.HueNeutral50 : "inherit", | ||
}, | ||
"& div[role='button']:hover": { | ||
backgroundColor: !isDisabled ? odysseyDesignTokens.HueNeutral50 : "inherit", | ||
}, | ||
"& a:focus-visible": { | ||
outlineOffset: 0, | ||
borderRadius: 0, | ||
outlineWidth: odysseyDesignTokens.FocusOutlineWidthMain, | ||
backgroundColor: !isDisabled ? odysseyDesignTokens.HueNeutral50 : "inherit", | ||
}, | ||
})); |
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 we're always doing !isDisabled
, would it make sense to use isEnabled
instead? It'd make the code easier to read, but I understand it doesn't follow the way HTML does it.
Something to think about. I prefer readability in these cases since these are regular div
s and not form elements.
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 kind of follows the same design as the other components like SideNav, etc. If you don't have a strong opinion I'll leave it like this for now to match the other code styles.
<NavItemContentClickContainer | ||
odysseyDesignTokens={odysseyDesignTokens} | ||
> | ||
<TopNavItemLabelContainer | ||
odysseyDesignTokens={odysseyDesignTokens} | ||
> | ||
{label} | ||
</TopNavItemLabelContainer> | ||
</NavItemContentClickContainer> | ||
) : !href ? ( | ||
<NavItemContentClickContainer | ||
odysseyDesignTokens={odysseyDesignTokens} | ||
role="button" | ||
tabIndex={0} | ||
onClick={onClick} | ||
onKeyDown={topNavItemContentKeyHandler} | ||
> | ||
<TopNavItemLabelContainer | ||
odysseyDesignTokens={odysseyDesignTokens} | ||
> | ||
{label} | ||
</TopNavItemLabelContainer> | ||
</NavItemContentClickContainer> | ||
) : ( | ||
<Link href={href} target={target} onClick={onClick}> | ||
<TopNavItemLabelContainer | ||
odysseyDesignTokens={odysseyDesignTokens} | ||
> | ||
{label} | ||
</TopNavItemLabelContainer> |
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 want to add some role
attributes in here. Some of these div
s are gonna be hard to select without the correct roles define, but looking through here and not seeing it visually, I can't quite say.
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.
hmm, not sure if any of these are clickable/selectable items. We will have links and buttons in the nav and the li -> div
container already has a button role when it is not a link
057c7dc
to
46b1305
Compare
46b1305
to
349ad58
Compare
OKTA-744808
Summary
Figma link
Testing & Screenshots