Description
As suggested by @eps1lon in #18128, I'm creating this issue as a place to discuss the Material-UI typings and whether they can be simplified to reduce the amount of time spent checking them, especially during editing.
There's always a tension between having the most exact types (which provide the best errors and editor completions) and having the fast type checking (the far end of the spectrum being any).
Issues like microsoft/TypeScript#34801 suggest that Material-UI might benefit from relaxing the exactness in order to gain back some perf.
From the repros I've investigated so far, a lot of the slowness seems to come from the large number of CSS property names (see https://github.com/mui-org/material-ui/blob/master/packages/material-ui-styles/src/withStyles/withStyles.d.ts). Not being an active CSS user myself, I have some naive questions:
- Am I correct in assuming that having a name and type for each well-known CSS property is incredibly valuable and isn't something we could give up?
- The
CSSPropertiestype appears to exist to support "pseudo selectors and media queries", which - according to my limited reading - seem to be named bags of additional CSS properties.
a) Are these bags themselves recursive or is there only a single additional layer? That is, do you go fromwidthtofoo.widthor tofoo.bar.width, etc? If it's just one level, simplifying the types cuts my local repro from 4.6 seconds down to 3.6 seconds (i.e. big win).
b) I played around with the types myself and couldn't come up with anything better thanBaseCSSProperties[keyof BaseCSSProperties], but - as I'm guessing you're aware - that's not a very useful type. It basically says that any CSS property can have the type of any (other) CSS property - that's only slightly better thanany. - In
StyleRules, if there are no properties, you get eitherCSSPropertiesor() => CSSProperties(which I will sloppily call "thunked CSSProperties"), which makes sense - theCSSPropertiesmight be lazy. If there are properties, you get eitherCreateCSSProperties<Props>, which makes sense - thePropsmight be required to compute theCSSProperties- or(props: Props) => CreateCSSProperties<Props>, which I didn't understand because it's effectively double-lazy - you have pass in thePropsonce to get theCreateCSSPropertiesand then again to get individual properties. Why is it "double thunked"?
Separately, I suspect, but have yet to demonstrate that IsEmptyInterface is too expensive for the benefit it provides. However, it's quite possible that I don't fully understand the benefits, so it would helpful to hear more.
Can we work together to find the right balance between accuracy and perf? (Note: "just make the compiler faster" is obviously a viable strategy, but I'd like to get the typings to a good place before we optimize for them.) Thanks!