[types] Moved types from OverridableComponent.d.ts to @material-ui/types

[mnajdova]

Another PR that prepares unnecessary changes for introducing the @material-ui/unstyled package. It moves the typings from @material-ui/core/OverridableComponent to @material-ui/types so that those can be reused in the new package. All previous typings from @material-ui/core/OverridableComponent are now just re-exported from @material-ui/types

[mui-pr-bot]

No bundle size changes

Generated by 🚫 dangerJS against 41d7b2b

[eps1lon]

We need to fork at some point in the chain of used types started from OverrideProps since that type is coupled with @material-ui/styles. StyledComponentProps or ClassNameMap should not be part of @material-ui/types.

[mnajdova]

We need to fork at some point in the chain of used types started from OverrideProps since that type is coupled with @material-ui/styles. StyledComponentProps or ClassNameMap should not be part of @material-ui/types.

CommonProps is the types that uses the StyledComponentProps, the ClassNameMap is added because it is used in StyledComponentProps. Not sure how we can fork it as this type is required in the OverridableComponent eventually. Do you have some suggestion?

[mnajdova]

Or we could exclude the StyledComponentsProps, as we are anyway not using the classes API anymore. And we can have a different typing for the CommonProps in core for now for the components that still use this API

[mnajdova]

@eps1lon can you check now?

[oliviertassinari]

From what I understand, the purpose of @material-ui/types is to host type utilities that are shared between different packages. Two questions:

1. Why create a distinction between JavaScript logic and TypeScript only logic. Would it make sense to merge @material-ui/types inside @material-ui/utils? (keeping them both for private usage)
2. It seems that these types don't need to be shared. Would it be simpler to host them in @material-ui/unstyled and have core import them from unstyled?

[oliviertassinari]

Should we remove it?

Suggested change

	/**
	* @deprecated Not used in this library.
	*/
	export type Simplify<T> = T extends any ? { [K in keyof T]: T[K] } : never;
	/**
	* @deprecated Not used in this library.
	*/
	// tslint:disable-next-line: deprecation
	export type SimplifiedPropsOf<C extends React.ElementType> = Simplify<React.ComponentProps<C>>;

[eps1lon]

Yes, please!

[eps1lon]

Why create a distinction between JavaScript logic and TypeScript only logic.

One has zero runtime cost the other doesn't. We don't create the distinction but reflect it. But I'm fine with unifiying them so that we have less stuff to maintain. Though we should really just move @material-ui/utils to @material-ui/internal to make it clear that we don't want to maintain a (perceived) public contract.

Would it be simpler to host them in @material-ui/unstyled and have core import them from unstyled?

That sounds more reasonable.

[mnajdova]

So is the best way to start moving to the unstyled package everything we find required along the way and avoid splitting utils and types to different packages?

If that's what we want I will close this and #23264 and start with just creating the unstyled package and move everything required there...

@eps1lon @oliviertassinari do we agree with this?

[oliviertassinari]

@mnajdova Sound fair. I'm not sure that we need to give up on the two existing pull requests.

[mnajdova]

@mnajdova Sound fair. I'm not sure that we need to give up on the two existing pull requests.

Let's open that one and we'll see if it can be broken down to more PRs