Skip to content

[PreviewCard] Create new component#469

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

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

Conversation

@atomiks

@atomiks atomiks commented Jun 27, 2024

Copy link
Copy Markdown
Contributor

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

mui-bot commented Jun 27, 2024

Copy link
Copy Markdown

@colmtuite

Copy link
Copy Markdown
Contributor

What's the reason behind not opening on focus?

@atomiks

atomiks commented Jun 27, 2024

Copy link
Copy Markdown
Contributor Author

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

colmtuite commented Jun 27, 2024

Copy link
Copy Markdown
Contributor

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

atomiks commented Jun 28, 2024

Copy link
Copy Markdown
Contributor Author

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

atomiks commented Jul 2, 2024

Copy link
Copy Markdown
Contributor Author

@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

colmtuite commented Jul 2, 2024

Copy link
Copy Markdown
Contributor

@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

atomiks commented Jul 2, 2024

Copy link
Copy Markdown
Contributor Author

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

Comment thread packages/mui-base/src/PreviewCard/Root/usePreviewCardRoot.ts
* The side of the anchor element that the preview card element should align to.
* @default 'bottom'
*/
side?: Side;

Copy link
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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.

Comment thread packages/mui-base/src/Popover/Root/usePopoverRoot.types.ts

@michaldudak michaldudak left a comment

Copy link
Copy Markdown
Member

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.

Comment thread docs/data/base/pages.ts Outdated
className,
ownerState,
extraProps: otherProps,
customStyleHookMapping: {

Copy link
Copy Markdown
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
Copy Markdown
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

Comment thread packages/mui-base/src/PreviewCard/Popup/PreviewCardPopup.types.ts Outdated

@michaldudak michaldudak left a comment

Copy link
Copy Markdown
Member

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