Skip to content
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: add Card variant #2332

Closed
wants to merge 1 commit into from
Closed

Conversation

zihanwang-okta
Copy link
Contributor

OKTA-794818

Summary

  • Add a new variant of the Card component
  • This new Card variant is to match the behaviours of the existing card/tile on enduser dashboard page
  • Existing behaviours on enduser dashboard:
    • click on the card to open the application or "Sign In To App" dialog if password is required
    • click on the menu button (... at the top right corner) to open the side drawer
Screenshot 2024-08-27 at 11 41 51 AM

Testing & Screenshots

  • I have confirmed this change with my designer and the Odyssey Design Team.

@zihanwang-okta zihanwang-okta requested a review from a team as a code owner August 27, 2024 15:43
@bryancunningham-okta
Copy link
Contributor

@zihanwang-okta Generally speaking, code looks pretty good to me. As a whole, I think it makes more sense to have an entirely different icon for when this button does something out of the ordinary. Feels a bit strange to me for seemingly the same button to provide different interactions in different situations. The user wouldn't know what to expect.

I know @jordankoschei-okta had some thoughts/ideas about how to implement this as well.

@bryancunningham-okta
Copy link
Contributor

I believe we landed on something like adding an AdditionalActionsButtonComponent or something like that. Where the consumer can pass in a button they want rendered in the top right. And they control what happens when it's clicked.

If we wanted to take that implementation to the next level: We could create an HOC component like CardAdditionalActionsButton and export it from Card that renders a <Button variant="floating"... we could make startIcon || endIcon and tooltipText required props here as well. Just to enforce the same look/feel as the normal more actions. Any thoughts on this?
cc// @KevinGhadyani-Okta @jordankoschei-okta @benlister-okta

@KevinGhadyani-Okta
Copy link
Contributor

I think this should use a different icon if it's going to open a drawer. Every time I click the 3-dots in Okta, don't feel right when the sidebar pops open. I expect to see an actions menu.

@bryancunningham-okta
Copy link
Contributor

I believe we landed on something like adding an AdditionalActionsButtonComponent or something like that. Where the consumer can pass in a button they want rendered in the top right. And they control what happens when it's clicked.

If we wanted to take that implementation to the next level: We could create an HOC component like CardAdditionalActionsButton and export it from Card that renders a <Button variant="floating"... we could make startIcon || endIcon and tooltipText required props here as well. Just to enforce the same look/feel as the normal more actions. Any thoughts on this? cc// @KevinGhadyani-Okta @jordankoschei-okta @benlister-okta

@KevinGhadyani-Okta Any thoughts on this approach? This would be how I'd probably attack it but wanted to try and get alignment on approach before @zihanwang-okta writes more code

Comment on lines 122 to 128
const openMenu = useCallback<MenuContextType["openMenu"]>((event) => {
if (onClickMenuButton) {
onClickMenuButton(event as React.MouseEvent<HTMLButtonElement>);
return;
}
setAnchorEl(event.currentTarget);
}, []);
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't know what MenuContextType["openMenu"] means, but we shouldn't have to ever use as on an event. The type can be set in the useCallback generic: useCallback<MouseEventHandlerK<HTMLButtonElement>>.

Comment on lines +204 to +216
render: ({ ...props }) => (
<Box sx={{ maxWidth: 262 }}>
<Card
{...props}
overline={props.overline}
title={props.title}
description={props.description}
onClickMenuButton={() => alert("Clicked on menu")}
onClick={() => alert("Clicked on Card")}
/>
</Box>
),
};
Copy link
Contributor

Choose a reason for hiding this comment

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

Instead of using ...props here, it'd be better to be explicit about what props we're passing.

Using {...props} makes it hard to see what props are being passed into Card.

@KevinGhadyani-Okta
Copy link
Contributor

@jordankoschei-okta Is this PR still needed or did your other work cover it?

@zihanwang-okta
Copy link
Contributor Author

@KevinGhadyani-Okta The new component AppTile should cover this variant to open the side drawer. So, we do not need this PR.

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.

3 participants