Closes #17454
Closes #20191

-<Component onChange={(event: React.ChangEvent<{}>) => {}} />
+<Component onChange={(event: React.SyntheticEvent) => {}} />

for:

• Accordion (former ExpansionPanel)
• BottomNavigation
• Slider
• Tabs

These components do not necessarily dispatch a react change event. They only passes whatever event triggered the change in value. I don't want to type it as exact as possible (FocusEvent | ClickEvent) because that restricts our implementation. We simply say that it's any react event at this point. You would have to narrow it later anyway which we can always do later if there are legitimate use cases.

The takeaway from this typing is that event.target is not interchangeable with a ref on the component. event.target could point to any element that the component rendered. It's a bit unfortunate that we overload what is usually considered a change event. We have to make the trade-off at some point: either when passing props (Slider behaves just like any other input: I pass a value and onChange) or when typing the onChange (event.target === event.currentTarget).

Removes onChange types from BottomNavigationAction and Tab. These are overridden anyway and considered private.

About OverrideableComponent changes

Let's say we have a component that implements the component like

function Button({ component: Component, ...other }) {
  return <Component {...other} />;
}

Previously we assumed that any prop that is implemented by Button is also forwarded to the passed component.

However, this is almost never the case e.g. in Tab we expect that the given component either doesn't implement onChange or as the same type.

The reality is that Tab does not forward onChange and therefore component never "sees" onChange.

There are some exceptions e.g. ButtonBase intercepts href but also passes it along. We currently expect the href to be a string but this isn't required if a component is passed.

Instead of expecting the passed component to extend the props of Button we should expect component to implement a separate interface e.g. in

function Button({ component: Component, external, target, ...other }) {
  return <Component target={external ? '_blank' : target} {...other} />;
}

the passed component needs to implement the target prop. It doesn't need to implement external nor should it ever expect to receive an external prop if it is used in <Button />.

This change is a bit scary but safe in next. I'll follow-up in a later PR with more test and experimentation if it makes sense to require component to implement a certain interface.

Future work

• remove problematic usage of React.ChangeEvent<{}>. It works structurally right now but has some implications that can't be expressed via types yet so we need to be careful with using it.