Using React.ComponentProps on the component created by styled cause significant delay in compilation

[chance-an]

Duplicates

• I have searched the existing issues

Latest version

• I have tested the latest version

Steps to reproduce 🕹

Link to live example:

A minimum repro can be seen here:

https://github.com/chance-an/styled_repro

Steps:

1. git clone the repository above
2. run npm install
3. run npm run build

Despite its simplicity, significant time was taken to compile the project.

If we comment out this line in index.tsx

const TestComponent = (props: React.ComponentProps<typeof StyledContainer>) => {

And uncomment this line

const TestComponent = (props: any)

the build can finish very quickly.

Separately, if we don't use styled from @mui/system/styled but use the one from @emotion/styled the issue goes away, and the project will be built very quickly as well.

Current behavior 😯

The project builds very slowly with the introduction of React.ComponentProps on the component returned by the styled of the @mui/system package.

This is a reduced example from an actual React project. In the full project, using React.ComponentProps on the component returned by styled will incur a javascript heap out of memory after a significantly prolonged compilation process.

For the minimum repro though, I cannot reproduce the javascript heap out of memory error, but only the slow compilation.

In the meantime, if an IDE like VS Code is being used, the editor also takes a significant amount of time loading intellisense. A "Code Helper" (Used by VS Code) process takes 100% CPU cycles at the same time. So it looks like VS Code's ts compiler is also stressed out.

Expected behavior 🤔

Using styled from @mui/system/styled should have a similar compilation performance as the one from @emotion/styled.

Context 🔦

A developer should be able to use styled and React.ComponentProps to extract the props of the produced component correctly without slowing down the compilation or crashing the node heap.

Your environment 🌎

npx @mui/envinfo

  No particular browser is involved with this issue. It's a compile-time issue.
  
  Output from `npx @mui/envinfo` goes here.
  
  System:
    OS: macOS 13.1
  Binaries:
    Node: 19.0.1 - ~/.nvm/versions/node/v19.0.1/bin/node
    Yarn: Not Found
    npm: 8.19.2 - ~/.nvm/versions/node/v19.0.1/bin/npm
  Browsers:
    Chrome: 110.0.5481.177
    Edge: Not Found
    Firefox: 106.0.5
    Safari: 16.2

[chance-an]

I debugged the TypeScript compiler and found the process got stuck at the recursiveTypeRelatedTo() function (reference).

I think what it's trying to do is to compare CSSSelectorObjectOrCssVariables with a target type. And this fails into a very deep recursion.

Checking the styleFunctionSx.d.ts file, it seems SystemStyleObject, and CSSSelectorObjectOrCssVariables have a circular dependency to each other, which seems to be the root cause of the issue. Do you think this can be avoided?

[mnajdova]

Can you check if it is similar when using React.ComponentPropsWithoutRef instead? I am asking because when working on #19113 this was one of the things that helped with improving the perf of the OverridableComponent. Can you please post the screenshot of a simple sample app following these steps: #19113 (comment).

We should definitely simplify a bit the types for the sx prop, but we need to be careful as we are likely going to have to loose some of them.

[chance-an]

React.ComponentPropsWithoutRef makes no difference. I still see the almost infinite recursion in TS compiler. But TS compiler knows to quit the recursion if it is too long. Hence the significant delay

5.11.11:

cace4e4:

Feel free to try out the sample project I provided above.

We should definitely simplify a bit the types for the sx prop, but we need to be careful as we are likely going to have to loose some of them.

What is your plan for the simplification, please? Would it resolve the circular references between SystemStyleObject, and CSSSelectorObjectOrCssVariables ?

[mnajdova]

What is your plan for the simplification, please? Would it resolve the circular references between SystemStyleObject, and CSSSelectorObjectOrCssVariables?

Not sure at this moment, but my thought was that probably we can limit the recursiveness by supporting nesting up until level 3 for e.g. Would be interesting to see if this will help.

[charpeni]

I've been able to reproduce with the repository you shared.

On my M1 Pro, it initially took 79.18s 🔥 :

npx tsc --incremental false --extendedDiagnostics

Files:                          962
Lines of Library:             28794
Lines of Definitions:        105372
Lines of TypeScript:             37
Lines of JavaScript:              0
Lines of JSON:                    0
Lines of Other:                   0
Identifiers:                 149364
Symbols:                    1446457
Types:                      1276739
Instantiations:              477666
Memory used:               1951154K
Assignability cache size:   1732887
Identity cache size:           1114
Subtype cache size:              20
Strict subtype cache size:        0
I/O Read time:                0.10s
Parse time:                   0.35s
ResolveModule time:           0.13s
ResolveTypeReference time:    0.01s
Program time:                 0.65s
Bind time:                    0.15s
Check time:                  78.39s
printTime time:               0.00s
Emit time:                    0.00s
Total time:                  79.18s

Using @emotion/styled dropped it to 0.88s:

npx tsc --incremental false --extendedDiagnostics

Files:                         962
Lines of Library:            28794
Lines of Definitions:       105372
Lines of TypeScript:            39
Lines of JavaScript:             0
Lines of JSON:                   0
Lines of Other:                  0
Identifiers:                149364
Symbols:                     95665
Types:                        3216
Instantiations:               7986
Memory used:               169886K
Assignability cache size:     1465
Identity cache size:            26
Subtype cache size:             13
Strict subtype cache size:       0
I/O Read time:               0.10s
Parse time:                  0.36s
ResolveModule time:          0.10s
ResolveTypeReference time:   0.01s
Program time:                0.63s
Bind time:                   0.14s
Check time:                  0.10s
printTime time:              0.00s
Emit time:                   0.00s
Total time:                  0.88s

Since this issue was originally created, TypeScript released version 5, which is way faster (1.62s) without having to change anything outside of the TypeScript version:

npx tsc --incremental false --extendedDiagnostics

Files:                         967
Lines of Library:            29751
Lines of Definitions:       105372
Lines of TypeScript:            40
Lines of JavaScript:             0
Lines of JSON:                   0
Lines of Other:                  0
Identifiers:                149144
Symbols:                    110487
Types:                      136628        <----
Instantiations:             164775        <----
Memory used:               249466K        <----
Assignability cache size:     5446
Identity cache size:            50
Subtype cache size:             20
Strict subtype cache size:       0
I/O Read time:               0.03s
Parse time:                  0.35s
ResolveModule time:          0.09s
ResolveTypeReference time:   0.01s
Program time:                0.52s
Bind time:                   0.15s
Check time:                  0.94s
printTime time:              0.00s
Emit time:                   0.00s
Total time:                  1.62s        <----

We can also notice the number of symbols, types, and memory used significantly dropping.