[typescript] Allow custom props for custom inputComponent

[eps1lon]

As a followup to #12591 which removed support for custom props when passing custom components. This might fix the issue described in #12691 but without a full repo this might not be the case.

Also improves typings when passing textarea or select.

There is still an issue which causes react to log warnings (unknown prop innerRef) when passing any intrinsic element via inputComponent. But this is a concern for the implementation not typescript.

[pelotom]

This is suffers from a version of the problem that stymied #11731: callback props can no longer infer their argument types. So whereas this worked before:

<Input inputProps={{ onFocus(e) {} }} />

with this PR it will no longer be able to infer the type of e and will assign it any (which is a type error if you have noImplicitAny enabled).

I'm a bit torn on this issue; I'd really like to use generics everywhere to accurately capture what happens when you override a component prop, but this is a fairly big backwards-breaking change. My strategy so far has been to wait and see if microsoft/TypeScript#26004 will get fixed in the near term, in which case I think we would be able to work around the issue. What do others think? /cc @mui-org/core-contributors

[eps1lon]

Did this work prior to #12591? I tested this locally and while vscode does infer the correct type the compiler does indeed throw no implicit any.

[eps1lon]

@pelotom How would you proceed with this change? If we don't merge it we should at least revert #12591.

I still prefer this solution over the previous one. I'd rather have some type-checking that requires me to explicitly type callbacks (which even is a tslint rule) than no type-checking at all which is the case prior to #12591 .

I think reverting #12591 and batching this for v4 is the safest route.

[pelotom]

I think reverting #12591 and batching this for v4 is the safest route.

Yeah, I kind of think we should defer this until we can apply the approach consistently across the entire library. I personally would be in favor of requiring type annotations on all callbacks for components with a component override prop, even though it would be a significant backwards-breaking change, because it would be correct. But that may be an ideal of purity not shared by other users of the library 🙂