Can the typings be simplified to improve performance?
See original GitHub issueAs 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 https://github.com/microsoft/TypeScript/issues/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
CSSProperties
type 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 fromwidth
tofoo.width
or 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 eitherCSSProperties
or() => CSSProperties
(which I will sloppily call “thunked CSSProperties”), which makes sense - theCSSProperties
might be lazy. If there are properties, you get eitherCreateCSSProperties<Props>
, which makes sense - theProps
might 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 theProps
once to get theCreateCSSProperties
and 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!
Pains
Issue Analytics
- State:
- Created 4 years ago
- Reactions:107
- Comments:116 (91 by maintainers)
Top GitHub Comments
88 upvotes on this comment: https://www.reddit.com/r/reactjs/comments/sbrjxs/choosing_the_right_component_library_for_your/hu1tqmy/
We need to change something.
Has there been any progress on this? Material-UI v5 is borderline unusable due to this.