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

[Toolbar] Add Toolbar components #1349

Open
wants to merge 51 commits into
base: master
Choose a base branch
from

Conversation

mj12albert
Copy link
Member

@mj12albert mj12albert commented Jan 21, 2025

Docs:

https://deploy-preview-1349--base-ui.netlify.app/react/components/toolbar

Demos:

Summary

  • parts: Root, Button, Input, Link, Group, Separator
  • focusableWhenDisabled prop on Button & Input
  • orientation prop
  • roving focus, loop prop
  • hotkey prop on Root [Toolbar] Support an optional hotkey #1454
  • grid layout with cols prop

Component integrations

The three demos linked above show all of these:

  • Dialog/AlertDialog
  • Menu
  • Menu with submenu
  • Popover
  • Select
  • Toggle/ToggleGroup
  • Tooltip
  • NumberField using Toolbar.Input
  • DirectionProvider
  • Input this will be a Toolbar.Input instead
  • Switch

Closes #661

@mj12albert mj12albert added the component: toolbar The React component. label Jan 21, 2025
Copy link

netlify bot commented Jan 21, 2025

Deploy Preview for base-ui ready!

Name Link
🔨 Latest commit 0f358c8
🔍 Latest deploy log https://app.netlify.com/sites/base-ui/deploys/67bc580539f0ec0009af31c5
😎 Deploy Preview https://deploy-preview-1349--base-ui.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

@mj12albert mj12albert force-pushed the feat/toolbar branch 2 times, most recently from f2b6d91 to 9c3111f Compare January 27, 2025 08:45
@mj12albert mj12albert changed the title feat/toolbar [Toolbar] Add Toolbar components Jan 28, 2025
@@ -22,6 +23,8 @@ export function useButton(parameters: useButton.Parameters = {}): useButton.Retu
rootElementName: elementNameProp,
});

const isCompositeItem = useCompositeRootContext(true) !== undefined;
Copy link
Member Author

Choose a reason for hiding this comment

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

This is to work around using Select.Trigger as a composite item by letting CompositeItem's tabIndex override the internal one in useButton

Like Menu.Trigger, select trigger manually sets tabIndex to keep a consistent "trigger remains focused after a select/menu item is select" behavior across browsers (Safari on iPadOS and iOS): https://github.com/mui/base-ui/blob/master/packages/react/src/select/trigger/useSelectTrigger.ts#L80

Copy link
Member

Choose a reason for hiding this comment

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

I wonder if this could cause problems with buttons nested inside other components within a toolbar (for example, a button inside a dialog opened from a toolbar would have this set to true, even though it's not a composite item).

Copy link
Member Author

Choose a reason for hiding this comment

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

for example, a button inside a dialog opened from a toolbar

Only if that button happened to use useButton as well, so in this case, a disabled Dialog.Close isn't affected, but a MenuTrigger in that dialog would be

What this affects is that when disabled, the HTML disabled attribute is never applied. Generally I think our components that use useButton already don't rely on the disabled attr to disable functionality anyway in order to support component/element replacement so it should be OK in most cases

Copy link
Member Author

@mj12albert mj12albert Feb 24, 2025

Choose a reason for hiding this comment

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

@michaldudak I also tried making it a isCompositeItem param instead of a check but it wasn't enough to handle this more common case: 575dc96

@mj12albert mj12albert force-pushed the feat/toolbar branch 7 times, most recently from 5dcde0c to 5fe85d2 Compare February 6, 2025 15:47
@aarongarciah
Copy link
Member

I found a strange behavior: the menu won't close when a submenu is open and you move the roving focus to the next toolbar element by pressing ➡️. Only the submenu is closed. See attached video.

Kapture.2025-02-07.at.07.45.58.mp4

@mj12albert

This comment was marked as outdated.

@mj12albert mj12albert force-pushed the feat/toolbar branch 2 times, most recently from 52068e8 to 557bbd4 Compare February 20, 2025 07:48
@mj12albert
Copy link
Member Author

mj12albert commented Feb 20, 2025

  • In the Triggers experiment, it seems like disabling controls doesn't work properly? When I disable the switch individually, that works. But when I disable the Dialog individually, that doesn't work. I saw this was called out before, at least in some capacity

OK it turns out various triggers have issues with the disabled state when they are not native button elements disabled with the disabled attribute (i.e. a custom element disabled using aria-disabled/data-disabled)

The fix depends on #1445

Before some of these experiments seemed to work occasionally because I was passing the disabled state 2-3 times, to the trigger, the root, and the toolbar button at the same time, but it should only be passed once to the toolbar button

@github-actions github-actions bot added the PR: out-of-date The pull request has merge conflicts and can't be merged label Feb 21, 2025
@michaldudak
Copy link
Member

I find restoring focus to the previously active item quite weird. I know ARIA guidelines suggest this ("If the toolbar has previously contained focus, focus is optionally set on the control that last had focus. Otherwise, it is set on the first control that is not disabled."), but the applications I checked don't work like that. cc @colmtuite

@@ -22,6 +23,8 @@ export function useButton(parameters: useButton.Parameters = {}): useButton.Retu
rootElementName: elementNameProp,
});

const isCompositeItem = useCompositeRootContext(true) !== undefined;
Copy link
Member

Choose a reason for hiding this comment

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

I wonder if this could cause problems with buttons nested inside other components within a toolbar (for example, a button inside a dialog opened from a toolbar would have this set to true, even though it's not a composite item).

@github-actions github-actions bot added PR: out-of-date The pull request has merge conflicts and can't be merged and removed PR: out-of-date The pull request has merge conflicts and can't be merged labels Feb 24, 2025
Comment on lines +60 to +61
if (elementName !== 'A') {
additionalProps.role = 'button';
Copy link
Member Author

Choose a reason for hiding this comment

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

This overwrites Select.Trigger's built-in role 😩

@github-actions github-actions bot removed the PR: out-of-date The pull request has merge conflicts and can't be merged label Feb 24, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: toolbar The React component. new feature New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Toolbar] Implement Toolbar
4 participants