Skip to content

[PreviewCard] Create new component#469

Merged
atomiks merged 17 commits intomui:masterfrom
atomiks:feat/HoverCard
Jul 23, 2024
Merged

[PreviewCard] Create new component#469
atomiks merged 17 commits intomui:masterfrom
atomiks:feat/HoverCard

Conversation

@atomiks
Copy link
Contributor

@atomiks atomiks commented Jun 27, 2024

Closes #451

@atomiks atomiks marked this pull request as draft June 27, 2024 11:23
@atomiks atomiks added the component: preview card Changes related to the preview card component. label Jun 27, 2024
@mui-bot
Copy link

mui-bot commented Jun 27, 2024

Netlify deploy preview

https://deploy-preview-469--base-ui.netlify.app/

Generated by 🚫 dangerJS against 54c6c28

@colmtuite
Copy link
Contributor

What's the reason behind not opening on focus?

@atomiks
Copy link
Contributor Author

atomiks commented Jun 27, 2024

What's the reason behind not opening on focus?

Hovercards (as the name seems to imply) are cards opened only via hover — the interactive content inside is not accessible via keyboard as you might expect if it opened on focus. Ariakit and Mantine don't open theirs on focus, while Radix does however.

@colmtuite
Copy link
Contributor

colmtuite commented Jun 27, 2024

Hovercards (as the name seems to imply) are cards opened only via hover

The name is irrelevant, we could change that to whatever. It's the experience that matters. It's not a well-defined pattern, so we can choose to do whatever we think is best.

the interactive content inside is not accessible via keyboard as you might expect if it opened on focus

It's a sighted only UI though right? And opening on focus still benefits sighted users. Non-sighted users don't benefit from the HoverCard at all, whether we open on focus or not?

@atomiks
Copy link
Contributor Author

atomiks commented Jun 28, 2024

It's a sighted only UI though right? And opening on focus still benefits sighted users. Non-sighted users don't benefit from the HoverCard at all, whether we open on focus or not?

The key problem is interactive content inside like a Follow button, there's no way to access that content without focus management if it opens on focus. That's why enforcing it to be hover-only is more appropriate.

  • Open Hover Card on focus
  • The Hover Card would steal focus if it moved to the Follow button like other components do with initial focus. The only valid method would be keeping focus on the trigger link, and letting the next tab access the Hover Card's contents. Pressing Esc places focus back onto the trigger, which should re-open the Hover Card since it opens when the trigger gains focus, leading to a loop (unless guarded). This pattern can be confusing - hence "enforcing it to be hover-only is more appropriate."

It looks like Wikipedia's Hover Cards do open on focus, but you can't access the interactive settings icon inside of it. Maybe it's ok that interactive content is inaccessible to keyboard users, for the benefit of being able to see a preview at all?

@atomiks atomiks changed the title [HoverCard] Create new component [PreviewCard] Create new component Jun 28, 2024
@colmtuite
Copy link
Contributor

@atomiks

  • The default delay needs to to updated to 600 to match the new Popover/Tooltip timings.
  • The delay should be present when the popup is triggered by focus.

@atomiks
Copy link
Contributor Author

atomiks commented Jul 2, 2024

@colmtuite Why do tooltips have 0 delay but preview cards have the hover's delay when either is triggered on focus? Since both are "secondary", shouldn't they behave the same?

@colmtuite
Copy link
Contributor

colmtuite commented Jul 2, 2024

@atomiks Becase PreviewCard almost always goes on a text link, so the popup is not necessarily desired when you focus it. Whereas Tooltip almost always goes on an icon button, and you might need to know what the button does asap.

Also, PreviewCard is almost always very significantly larger than Tooltip, so it is extremely obnoxious when it instantly appears upon focusing its trigger. The Tooltip is much less obnoxious.

@atomiks
Copy link
Contributor Author

atomiks commented Jul 2, 2024

Becase PreviewCard almost always goes on a text link, so the popup is not necessarily desired when you focus it. Whereas Tooltip almost always goes on an icon button, and you might need to know what the button does asap.

Couldn't the same argument be applied to a link, if the text can be as ambiguous as an icon button? In some circumstances you may want to preview of the link's contents as soon as possible as well.

Instagram's preview cards have 0 delay, but Wikipedia's have the delay. I think I do prefer Wikipedia's method (that you're suggesting) because of your next point:

Also, PreviewCard is almost always very significantly larger than Tooltip, so it is extremely obnoxious when it instantly appears upon focusing its trigger. The Tooltip is much less obnoxious.

The cards on Instagram can block a lot of content so this makes more sense to me. An API change to configure hover + focus delay triggers individually may be a bit problematic. I think we can leave the configuration for this for now, and have the delay be applied equally to hover + focus triggers.

@colmtuite
Copy link
Contributor

I think we can leave the configuration for this for now, and have the delay be applied equally to hover + focus triggers.

I think it's possible that we don't ever need to configure the triggers independently. But this is a good first step in any case. 👍

@atomiks atomiks marked this pull request as ready for review July 2, 2024 09:53
Comment on lines +10 to +13
const { delayType = 'rest', delay, closeDelay, animated = true } = props;

const delayWithDefault = delay ?? OPEN_DELAY;
const closeDelayWithDefault = closeDelay ?? CLOSE_DELAY;
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
const { delayType = 'rest', delay, closeDelay, animated = true } = props;
const delayWithDefault = delay ?? OPEN_DELAY;
const closeDelayWithDefault = closeDelay ?? CLOSE_DELAY;
const { delayType = 'rest', delay = OPEN_DELAY, closeDelay = CLOSE_DELAY, animated = true } = props;

Why not use the destructuring for assigning the defaults?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The prop-types/docs api gen doesn't allow variables as defaults when destructuring

Copy link
Member

Choose a reason for hiding this comment

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

Damn, I am adding it on the code-infra topics for next week.

* The side of the anchor element that the preview card element should align to.
* @default 'bottom'
*/
side?: Side;
Copy link
Member

Choose a reason for hiding this comment

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

I think we should use rtl safe values here, like start/end. I know the type comes from Floating UI, but we can change the values on a component level.

Copy link
Member

Choose a reason for hiding this comment

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

For example, for alignment, we use: start, center, and end. We would be consistent.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You're right that we can support logical sides on a component level, but they are more complex to understand compared to physical sides, and logical alignments are far more useful for many cases, not only RTL. This is an issue for the anchor positioning hook though, so it shouldn't relate to this PR itself.

Copy link
Member

@michaldudak michaldudak left a comment

Choose a reason for hiding this comment

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

Looks good overall. I have a few minor remarks.

className,
ownerState,
extraProps: otherProps,
customStyleHookMapping: {
Copy link
Member

Choose a reason for hiding this comment

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

This could be extracted to a const outside of the component so it's not recreated on every render

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 noticed our other components have it inlined sometimes, and useComponentRenderer passes it as a memo dependency, so they'll need to be updated as well

Copy link
Member

@michaldudak michaldudak left a comment

Choose a reason for hiding this comment

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

LGTM

@atomiks atomiks merged commit 00aebe3 into mui:master Jul 23, 2024
@atomiks atomiks deleted the feat/HoverCard branch July 23, 2024 01:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

component: preview card Changes related to the preview card component.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[PreviewCard] Create the unstyled component

5 participants