[interactive elements] remove duplicated disabled prop

[seongminn]

• I have followed (at least) the PR section of the contributing guide.

getButtonProps selects and applies either disabled or aria-disabled appropriately. But the disabled attribute was always being added separately, meaning it was always present regardless.

Fixes #3649

[pkg-pr-new]

• vite-css-base-ui-example

  pnpm add https://pkg.pr.new/mui/base-ui/@base-ui/react@3650
  

  pnpm add https://pkg.pr.new/mui/base-ui/@base-ui/utils@3650
  

commit: 0edf41e

[mui-bot]

Bundle size report

Bundle	Parsed size	Gzip size
@base-ui/react	▼-282B(-0.07%)	▼-91B(-0.07%)

Details of bundle changes

---

Check out the code infra dashboard for more information about this PR.

[netlify]

✅ Deploy Preview for base-ui ready!

Name	Link
🔨 Latest commit	0edf41e
🔍 Latest deploy log	https://app.netlify.com/projects/base-ui/deploys/695720f2bc246300086204c9
😎 Deploy Preview	https://deploy-preview-3650--base-ui.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

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

[seongminn]

When focusableWhenDisabled is true, aria-disabled should be applied instead of disabled. Accordingly, I modified the test code for ComboboxChipRemove.

Additionally, when the disabled attribute was added to ComboboxChipRemove, it was not composing with the disabled attribute passed to ComboboxRoot. So I fixed that as well.

[atomiks]

Thanks for the fixes - what is this particular file (and Decrement) changed for?

[seongminn]

As with other components, it appropriately merges the disabled passed from the Root component and the disabled passed from the Increment component.

And unlike other components, NumberField recalculates disabled within useNumberFieldButton. Therefore, it separately creates composedDisabled. If declaring this variable is unnecessary, directly assigning it as shown below is also valid.

const { disabled = false, ...props } = useNumberFieldButton({
    // ....
    disabled: disabledProp || contextDisabled,
});

[atomiks]

Ah I see that you're checking the result of the internal calculation:

disabled: disabled || (isIncrement ? isMax : isMin),

I would do this calculation before passing to useNumberFieldButton, that way it's composed of all the states and NumberFieldIncrement.State has the correct disabled state, without needing the destructure props collection?

Furthermore, I realized that the Number Field buttons should use focusableWhenDisabled: true in useButton so focus isn't lost when it reaches the min/max value.

[seongminn]

Before passing it to the useNumberFieldButton hook, completing the calculation of the disabled property would look like this:

const composedDisabled = disabledProp || contextDisabled;
const isMax = value != null && value >= maxWithDefault;

```ts
const { disabled = false, ...props } = useNumberFieldButton({
    // ...
    disabled: composedDisabled || isMax,
});

However, doing this might allow the isDisabled value to change when calculated inside useNumberFieldButton.

// current
const isDisabled = disabled || readOnly || (isIncrement ? isMax : isMin);

// changed
const isDisabled = disabled || readOnly;

But I don't think this difference is particularly significant. So, I think it would be okay to change the internal logic of the useNumberFieldButton hook. What do you think?

[atomiks]

Yes, it's better as it reduces the repetition in the event handlers

It should look like this:

const isMax = value != null && value >= maxWithDefault;
const disabled = disabledProp || contextDisabled || isMax;

const props = useNumberFieldButton({
    disabled,
});

Then internally,

const isDisabled = disabled || readOnly;

Since disabled has the min/max condition

[seongminn]

Thank you for your feedback. I did it here

[atomiks]

Thank you - pnpm prettier needs to be run

[seongminn]

I did it here!