Open oliviertassinari opened 6 days ago
We went with onValueChange
for a few reasons:
value
prop to be consistent with other controllable properties like open
and onOpenChange
.setValue
setter in directly with no wrapper function needed: onValueChange={setValue}
.event
is still accessible and passed as a second argument: onValueChange(value: string, event: Event)
. For the most basic/simple controlled usage, you don't need to care about the event
. Since it's secondary, the way to access it is also secondary for optimal DX.
Steps to reproduce
Link to live example: (required)
Steps:
Current behavior
New API structure for the
onValueChange
prop.Expected behavior
The
onValueChange
API signature looks different from what we used to have. I'm missing the rationale/the value for it to be different.https://github.com/mui/base-ui/blob/78d4abd6a72b0e3d783aa7a09bfda8c7a7518b88/packages/mui-base/src/NumberField/Root/useNumberFieldRoot.ts#L67
Shouldn't this be called
onChange
?event
. In Material UI v0, we used to do a mix of a bunch of different signatures, we always needed to expose the event, so it seemed simpler to default to expose theevent
first, and the value second, and optional 3rd argument, and a catch all in a 4th argument.https://mui.com/base-ui/react-number-input/#events matches my expectations.
Overall, I think that this raises the question of API consistency. I see no reason for it to differ between MUI X, Material UI, and Base UI (the opposite, it's part of the value of doing all under a single roof, consistency in the DX). So I think it should be our aspiring goal. https://mui.com/material-ui/guides/api/#controlled-components we meant to be our source of truth up until now.
I see a few action points:
Context
I saw this from the difference API used between number input and autocomplete in https://github.com/mui/base-ui/issues/579#issuecomment-2344004679.
Your environment
``` Don't forget to mention which browser you used. Output from `npx @mui/envinfo` goes here. ```npx @mui/envinfo
Search keywords: -