[Select][base] Add event parameter to the onChange callback

[michaldudak]

The SelectUnstyled and MultiSelectUnstyled onChange callbacks did not have event as the first parameter, leading to inconsistency with other components and native HTML elements.
This PR adds the event parameter as the first one and moves the newly selected value to the second position. Because of this, it's a breaking change.

// before
<SelectUnstyled onChange={(newValue) => { /* ... */ }} />

// after
<SelectUnstyled onChange={(event, newValue) => { /* ... */ }} />

I've also changed the signature of Joy Select's onChange to match the one in Base (CC @siriwatknp).

The onHighlightChange in useListbox while not exposed by Select and MultiSelect was also updated.

Closes #33901

[mui-bot]

Details of bundle changes

Generated by 🚫 dangerJS against efebd10

[siriwatknp]

@michaldudak I can help update the Joy Select demos if you'd like.

I added @mui/joy label because it is a breaking change for Joy UI as well.

[michaldudak]

Thanks a lot, there's no need to, I can take a look at them myself.
BTW, why are there no TS demos in Joy?

[siriwatknp]

@michaldudak Can I use 'event.target.value' for getting the selected option?

[michaldudak]

@siriwatknp no. The event.target could be a <li> that's clicked on. It doesn't have a meaningful value. Besides, in some cases event could be null, so your safest bet would be to use the second parameter. I'd like to standardize this pattern across all input components - have an event as a first parameter and the changed value as the second one.

[siriwatknp]

@siriwatknp no. The event.target could be a <li> that's clicked on. It doesn't have a meaningful value. Besides, in some cases event could be null, so your safest bet would be to use the second parameter. I'd like to standardize this pattern across all input components - have an event as a first parameter and the changed value as the second one.

👍 for leaning toward consistency (similar to the onChange in Tabs).

[siriwatknp]

👍 Looks good to me.

[oliviertassinari]

It's great to see this change of API :D

[oliviertassinari]

💯 to remove these shorthands. As far as I know, these are the first in the codebase. I would argue that it's confusing for developers that are getting started, and less clear for experienced developers that are coming back to an old codebase. I think that e > event only for writing code, but if we assume that this code will be read a lot more than written, then I think it would be better with:

Suggested change

	e: React.MouseEvent | React.KeyboardEvent | React.FocusEvent | null,
	event: React.MouseEvent | React.KeyboardEvent | React.FocusEvent | null,

[michaldudak]

All right, will do a follow-up PR.

[oliviertassinari]

based on the comment above, I think that it either:

Suggested change

	<CustomSelect value={value} onChange={(e, newValue) => setValue(newValue)}>
	<CustomSelect value={value} onChange={(event, newValue) => setValue(newValue)}>

or

Suggested change

	<CustomSelect value={value} onChange={(e, newValue) => setValue(newValue)}>
	<CustomSelect value={value} onChange={(_, newValue) => setValue(newValue)}>