Material-ui: 성능 향상을 위해 타이핑을 단순화할 수 있습니까?

나는 material-ui 유형에 익숙하지 않지만 이러한 질문에 답하려고 합니다.

1. 예, 실제 웹 표준에서 선언된 모든 CSS 속성에 대한 완전한 지원이 유용합니다.
2. a) 우리의 경우 2보다 큰 깊이를 사용하지 않지만 이와 같은 경우는 충분히 가능합니다.
   ```타이프스크립트
   const 스타일 = (테마: 테마) =>
   createStyles({
   somediv: {
   '&:호버 버튼': {
   가시성: '가시성',
   불투명도: 1,

                ':after': {
                    content: 'x',

                    [theme.breakpoints.up('lg')]: {
                        content: 'close',
                    },
                }
            },
        }
    });
```
b) I do not understand why `BaseCSSProperties[keyof BaseCSSProperties]` is needed there

1. (props: Props) => CreateCSSProperties<Props> 는 필요하지 않다고 생각합니다. 우리는 material-ui 유형의 버전에서 이 유형을 제외했고 나쁜 일은 일어나지 않았습니다.

버전 3.9.3의 유형 구현을 살펴볼 가치가 있을 것입니다. 이 버전에서는 유형 검사가 충분히 빠르고 타이핑이 좋았기 때문입니다.

먼저 이 문제에 대해 관심을 갖고 조사해 주셔서 감사합니다. 유형의 어느 부분이 느린지 여부를 누군가가 벤치마킹하도록 하는 것은 매우 유용합니다.

1. 잘 알려진 각 CSS 속성에 대한 이름과 유형을 갖는 것이 매우 가치 있고 포기할 수 있는 것이 아니라고 가정하는 것이 맞습니까?

여기에서 편견이 없는 것은 불가능합니다. 더 넓은 생태계를 보더라도 포기할 수 없다고 생각합니다. Chrome devtools에는 이 기능이 있으며 style 소품을 CSSProperties 등으로 입력합니다. IDE에서 브라우저로 전환하는 모습을 볼 수 없고 텍스트 장식인지 글꼴 장식인지 확인할 수 없습니다. 텍스트 변환.

1. [...]
   이 가방 자체가 재귀적입니까 아니면 추가 레이어가 하나만 있습니까?

우리가 사용하고 있는 CSS-in-JS 솔루션을 확인해야 합니다. 기술적으로 CSS의 미디어 쿼리는 재귀적일 수 있습니다. 나는 이 재귀성을 없애고 보고를 받는지 확인하고 싶습니다. 기술적으로 중첩된 미디어 쿼리는 and 연산자를 사용하여 병합할 수 있습니다. 우리는 그것을 두 가지 수준으로 제한해야 합니다. 하나는 미디어 쿼리용이고 다른 하나는 의사 선택기용입니다. 이것은 여전히 ​​IMO 유형을 확인해야 합니다.

const styles = {
  root: {
    '<strong i="18">@media</strong> (max-width: 12cm)': {
      ':hover': {}
    }    
  }
}

@oliviertassinari를 쓰는 자신을 본 것입니까?

1. [...]
   CSSProperties - 또는 (props: Props) => CreateCSSProperties, 효과적으로 이중 게으르기 때문에 이해하지 못했습니다. CreateCSSProperties를 얻기 위해 Props를 한 번 전달한 다음 개별 속성을 얻기 위해 다시 전달했습니다. 왜 "더블 썽크"입니까?

인수 자체가 속성 모음이 아니라 함수인 경우 테마가 필요합니다. 스타일은 두 가지 다른 종류의 속성 모음에 따라 달라질 수 있습니다. 테마(React의 컨텍스트 API를 통해 사용 가능) 또는 소품(구성 요소에 직접 전달됨):

makeStyles({ root: { color: 'blue' }}); // A
makeStyles(theme => ({ root: { color: theme.color } })); // B
makeStyles({ root: props => ({ color: props.color})}); // C
makeStyles({ root: { color: props => props.color } }); // D: same as C, only exists for dev ergonomics
makeStyles(theme => ({ root: props => ({ color: props.color || theme.color }) })); // E: what you called "double-lazy"

성능 향상을 위한 지연 평가보다는 컨텍스트와 소품을 사용할 수 있을 때까지 기다려야 합니다.

이와 별도로 IsEmptyInterface가 제공하는 이점에 비해 너무 비싸다는 것을 의심하지만 아직 입증하지 못했습니다. 다만, 이점을 충분히 이해하지 못할 가능성이 있으니, 좀 더 들어보시면 도움이 될 것 같습니다.

이것이 사용되는 한 가지 경우가 있습니다.

고려하다

const useStaticStyles = makeStyles({ root: { color: 'blue' } });
const useDynamicStyles= makeStyles({ root: { color: props =>  props.color } })
function Component() {
  const staticClasses = useStaticStyles(); // No error
  const throwingClasses = useDynamicStyles(); // $ExpectError
  const dynamicClasses = useDynamicStyles({ color: 'blue' });
}

makeStyles 에서 반환된 함수의 호출 서명을 유추하려면(즉, useSomeStyles 와 같은 이름의 후크). makeStyles 어떤 스타일 백이 전달되었는지 확인해야 합니다. style bag 에 사용된 props 유형을 유추 하는 {} 유형을 유추합니다. 그런 다음 IsEmptyInterface Props의 유추된 유형을 확인하고 한 분기에 대해 0 매개변수가 있는 호출 서명을 사용하고 다른 분기에 대해 유추된 props 유형( StylesRequireProps 및 StylesHook .

간단히 말해서: useStaticStyles({}) 또는 useStaticStyles(null as any) 를 작성하지 않아도 됩니다. https://github.com/mui-org/material-ui/pull/14019 에서 . 나는 우리가 호출 서명을 결정하는 회로를 단락시킬 수 있다고 생각합니다. 조건부 유형을 사용하는 대신 호출 서명을 오버로드할 수 있습니까?

이 "기능"의 문제는 고급 사용자가 이유를 이해한다면 null as any 사용하는 데 문제가 없다는 것입니다. 필요하지 않더라도 빈 객체를 전달하는 것도 괜찮습니다. 그러나 Material-UI나 TypeScript에 익숙하지 않으면 매우 혼란스럽습니다. 특히 대부분의 스타일링은 어쨌든 소품을 기반으로하지 않기 때문에.

대부분의 경우 유형 검사기가 스타일링 솔루션으로 가득 차 있는 것 같습니까? 나는 우리 구성 요소에 대한 호출 서명, 즉 대부분의 시간이 소요되는 props를 예상했을 것입니다.

withStyles 또는 makeStyles 사용을 구체적으로 살펴보기 위해 더 많은 리포지토리를 크롤링할 수 있습니다. 지금까지 props 사용법만 살펴보았습니다.

@oliviertassinari를 쓰는 자신을 본 것입니까?

@eps1lon 코드베이스에서 이 중첩이 몇 번 발생했습니다(예: <strong i="8">@media</strong> (hover: none) ). 그러나 핵심 구성 요소에는 그리 자주 사용되지 않습니다. 나는 그것이 동일한 사용자 영역이라고 상상합니다. 그것은 분명히 절충안의 일부일 수 있습니다.

@beholderrk

1. 나는 충분히 생각했지만, 내가 물어볼 수도 있다고 생각했다.
2. ) 깊이 2는 표현할 수 있어야 합니다. 깊이 1보다 약간 더 많은 중복이 있을 것입니다.
   b) 이 문제에 대해 머리를 쓰는 데 꽤 오랜 시간이 걸렸고 텍스트 대신 직접 설명할 수 있으면 좋겠습니다. 기본적으로 인덱스 시그니처는 모든 속성이 동일한 유형을 갖는다는 의미입니다. 그것은 그들 모두에 대해 작동하는 유형을 지정하는 경우에만 작동할 수 있습니다. 그렇게 하는 한 가지 방법은 모든 속성 유형의 합집합을 구성하는 것입니다. BaseCSSProperties[keyof BaseCSSProperties] - 그러면 모든 속성에 호환 가능한 유형이 있다는 것이 사실이 됩니다. 예를 들어 CSS에서 가질 수 있는 유일한 속성이 name: string 및 width: number 합니다. 두 속성 모두에서 작동하는 인덱스 서명을 지정하는 한 가지 방법은 모든 속성이 string | number 라고 말하는 것입니다. 좋지 않습니다. name 는 number width 가 되지 않고 string 가 되지 않습니다. 하지만 작동합니다. 진짜 문제는 당신이 원하는 것을 실제로 표현할 수 없다는 것입니다(적어도 우리가 결정할 수 있는 한 - 그것을 하는 "영리한" 해킹이 있을 수 있습니다). 실제로 유형에 name: string , width: number 또는 x: CSSProperties 가 포함되어 있다고 말하고 싶습니다. 여기서 x 는 name 또는 width 이 아닙니다.
3. @eps1lon 이 이에 대해 할 말이 있는 것처럼

정상 작동이 확인된 기준선은 매우 유용합니다. 혹시 링크가 있으신가요?
수정: 찾았습니다.

@eps1lon 대화에 참여하게 되어

1. 여기에는 논쟁의 여지가 없습니다. 전체 대화를 방해할 수 있기 때문에 일찍 여쭤보겠습니다.
2. 두 개의 레이어가 가능한 것 같습니다(유형이 여전히 대부분 쓸모가 없다는 주목할만한 경고와 함께). 초안을 작성할 수 있는지 알아보겠습니다.
3. 맥락이 부족해서 테마와 소품이 다른지 명확하지 않았습니다. 그렇다면 구조가 의미가 있습니다. 명확히 해 주셔서 감사합니다.

isEmptyInterface 와 관련하여 속성 매개변수를 (예:) useStaticStyles 옵션으로 만들 수 있습니까? 호출자가 예상할 때 생략할 수 있다는 점에서 덜 정확하지만 유형 검사가 훨씬 저렴합니다. 내가 말했듯이, 나는 당신을 위한 숫자나 어떤 것도 가지고 있지 않습니다. 그것은 단지 내 추측일 뿐입니다.

2(b)에 대해 어떻게 생각하십니까? 기본적으로 모든 속성 이름이 허용되고 반환 유형이 많은 것 중 하나일 수 있다고 말하므로 해당 유형은 많은 가치를 제공하지 않는 것 같습니다.

isEmptyInterface와 관련하여 (예를 들어) useStaticStyles에 대한 properties 매개변수를 선택사항으로 만들 수 있습니까?

먼저 호출 서명을 오버로드하는 실험을 하고 이것이 어떤 영향을 미치는지 확인하고 싶습니다. 그런 다음 항상 선택 사항으로 만들어 소리를 줄이려고 합니다. 거의 모든 사용 사례에서 한 번만 호출하므로 실수를 한 번만 저지를 가능성이 높기 때문에 소리를 덜 들리게 하는 것이 평소보다 더 안전해 보이며 매우 빠르게 나타납니다. 우리에게 많은 성과를 거두지 못한다면 판매하기 어려울 것입니다. 저는 원래 문제(https://github.com/microsoft/TypeScript/issues/34801#issue-514055289)에 대해 생성된 리포지토리를 사용합니다.

2(b)에 대해 어떻게 생각하십니까? 기본적으로 모든 속성 이름이 허용되고 반환 유형이 많은 것 중 하나일 수 있다고 말하므로 해당 유형은 많은 가치를 제공하지 않는 것 같습니다.

실수로 건너뛰었습니다. IsEmptyInterface 실험 후에 살펴보겠습니다.

@eps1lon 전적으로 동의합니다. 제거하는 것이 상당한 성능 향상이 아닌 경우 isEmptyInterface 유지합니다.

#19320을 사용하여 함수 오버로드가 동일한 결과를 달성하는 일부 복잡한 조건부 유형을 제거했습니다( IsEmptyInterface 및 모든 부울 논리 유형 제거). 코드가 적은 것 외에는 우리에게 많은 것을 얻지 못한 것 같습니다.

현재 TS 3.2.4와 3.7.4 사이를 왔다갔다 하고 있다고 덧붙이고 싶습니다. 우리의 유형 테스트 스위트는 3.2.4에 비해 3.7.4에서 50% 느리게 실행됩니다(~90초 대 50초).

CSSProperties의 깊이를 제한하고 미디어 쿼리 및 의사 선택기에 대한 지원을 완전히 제거할 수 있는지 계속 조사하겠습니다. 그것들을 입력하지 않는 것은 실제로 옵션이 아닙니다. 유형 검사기는 합리적인 시간에 이를 확인할 수 있어야 합니다.

유형 검사기가 실제 병목 현상일 수 있습니다. 어떤 버전의 성능이 적중되었는지 조사할 수 있습니다.

3.2.4 및 3.7.4에서 실행 중인 명령을 저에게 보내주시면 로컬에서 프로파일링할 수 있습니다. 그러나 경험에 따르면 원인은 3.2.4 이후 추가된 바람직한 추가 검사로 판명될 것입니다. (그리고 나는 "0s"가 오타라고 가정합니다 - 아마도 "40s" 또는 "50s"?)

CSSProperties와 관련하여 속성 이름과 유형을 유지하는 것이 매우 중요하다는 데 동의합니다. 그러나 적당한 시간 안에 확인하는 것보다 더 중요한 것이 있다고 생각합니다. 첫 번째 문제는 유형 시스템에서 원하는 모양을 실제로 표현할 수 없다는 것입니다. 문제에 대한 일반적인 해결책을 찾는 데 시간을 할애할 것 같습니다. 귀하가 해당 토론에 참여하는 데 관심이 있다고 가정해도 될까요?

여러 버전의 컴파일러를 비교하기 위한 스크립트가 있으므로 실행하기를 원하는 상당히 안정적인 테스트를 식별할 수 있다면 시간 경과에 따른 속도 저하를 차트로 파악할 수 있습니다.

(그리고 나는 "0s"가 오타라고 가정합니다 - 아마도 "40s" 또는 "50s"?)

죄송합니다. 50대입니다.

3.2.4 및 3.7.4에서 실행 중인 명령을 저에게 보내주시면 로컬에서 프로파일링할 수 있습니다.

그것을 구현하는 모든 작업 공간에서 동일한 명령을 실행하는 루트의 yarn typescript 입니다. 예를 들어 yarn workspace @material-ui/styles run typescript 는 tslint 및 dtslint 의 $ExpectError 유형을 테스트합니다. 3.7.4에서 몇 가지 오류가 발생하여 테스트를 조정해야 했습니다(#19242 참조).

첫 번째 문제는 유형 시스템이 실제로 원하는 모양을 표현할 수 없다는 것입니다.

그만큼 의심했다. 인덱스 서명이 있는 개체와 "구체적인" 모양을 혼합하는 방식은 단지 해결 방법인 것 같습니다.

나는 당신이 그 토론에 참여하는 데 관심이 있다고 가정해도 될까요?

분명히. 나는 비재귀 CSSProperties에 대해 조금 더 시간을 할애한 다음 이러한 유형에서 우리가 찾고 있는 것을 설명하기 위해 조금 더 테스트를 작성할 것입니다. 다른 css-in-js 스타일링 솔루션이 비슷한 성능 병목 현상을 일으키지 않을까 생각합니다.

나는 내일 그 명령을 시도할 것이다(나는 내가 태평양 시간에 있고 미국 공휴일을 준수한다고 언급해야 한다고 가정한다).

인덱스 서명이 있는 개체와 "구체적인" 모양을 혼합하는 방식은 단지 해결 방법인 것 같습니다.

감사합니다. 어떻게 표현해야 좋을지 고심하고 있습니다. 예, 색인 서명이 원하는 작업을 수행하지 않는 것이 맞습니다. 변형 가능성에 대해 몇 가지 생각이 있지만 성능에 미치는 영향을 조사해야 합니다.

다른 css-in-js 스타일링 솔루션이 비슷한 성능 병목 현상을 일으키지 않을까 생각합니다.

매우 그렇다. 우리는 여러분을 위해 하는 모든 것이 전체 생태계를 개선하기 위해 일반화될 수 있기를 바랍니다.

분명한 것을 놓치고 있는 것 같지만 현재 막혀 있습니다. 먼저 Windows를 포기했습니다. Linux에서 더 잘 작동하는 것 같습니다. 자세히 알아보려면 알려주세요. 둘째, yarn typescript 를 실행하도록 할 수 있습니다. 제가 말할 수 있는 한 깔끔하게 - 하지만 순수한 tsc가 아닌 tslint를 실행하는 것으로 보입니다. 동일한 tsconfig.json에서 tsc를 실행하면(특히 스타일로 테스트 중입니다) ~40개의 오류가 발생합니다. 내가 뭘 잘못하고 있죠? 프로파일링 목적을 위해 repo를 단일 tsc 호출로 줄이는 것이 매우 도움이 될 것입니다.

@amcasey yarn typescript 는 컴파일이 아니라 유형을 테스트하는 것입니다. 확실히 Typed 리포지토리에서 사용된 것과 유사한 설정을 사용하고 있습니다. packages/* TypeScript 파일은 거의 항상 $ExpectError 포착하는 통과하거나 실패해야 하는 명령문의 묶음입니다.

내가 최고 "실제"테스트 케이스가 사용하고있는 것 tsc 통해 우리의 문서에 yarn workspace docs run tsc -p tsconfig.json 추가 한 후 skipLibCheck: true 및 noEmit: true 에 ./docs/tsconfig.json :

--- a/docs/tsconfig.json
+++ b/docs/tsconfig.json
@@ -3,6 +3,8 @@
   "include": ["types", "src/pages/**/*"],
   "compilerOptions": {
     "allowJs": false,
-    "noUnusedLocals": true
+    "noUnusedLocals": true,
+    "noEmit": true,
+    "skipLibCheck": true
   }
 }

@eps1lon 명확히

이 설정은 완벽합니다. 확인 시간이 3.3과 3.4 사이에서 두 배인 것을 보고 있습니다.

| 버전 | 시간 확인 |
|-|-|
| 3.2 | 16.71초 |
| 3.3 | 16.79초 |
| 3.4 | 35.25초 |
| 3.5 | 21.40초 |
| 3.6 | 23.10초 |
| 3.7 | 27.39초 |

조금 더 파고들겠지만 조건부 유형의 3.3 구현은 불완전하고 3.4 구현은 느리고 3.5 구현은 양호하다고 들었습니다. 따라서 불행히도 이것은 예상됩니다.

특히 이 변경으로 인해 이 버그에 설명된 대로 속도가 느려졌다고 생각 합니다 .

나는 3.5와 3.7 사이에 검사를 실행하는 데 걸리는 시간이 6초 증가했다는 사실을 알게 되었습니다. 꽤 상당해 보입니다.

@embeddedt 이 숫자는 각 버전의 단일 실행에서 나온 것이므로 약간의 노이즈가 있을 수 있습니다. 그러나 내가 파고들어서 뭔가를 찾을 수 있는지 확인하겠습니다.

Linux VM에서 다시 실행했는데 3.7은 3.5보다 일관되게 20-25% 느렸습니다.

동일한 빌드의 연속 실행이 ~5%씩 다르고 3.5와 3.6 또는 3.6과 3.7 사이의 차이가 ~10%에 불과하기 때문에 이것은 이등분하기 매우 어려운 것으로 입증되었습니다.

내가 알아차린 한 가지 의심스러운 점은 styled-components 가 TS >= 3.7에 대해 별도의 .d.ts 파일을 제공하므로 비교가 사과와 사과가 아닐 수 있다는 것입니다.

놀랍게도 새로운 styled-components 유형이 더 빨라 보입니다. 사과와 사과를 비교하면 여전히 조사가 더 쉬울 것입니다.

영리한 솔루션이 생각나지 않아 병합으로 컴파일 시간 병합을 플롯하고 스파이크를 찾습니다. 내일 숫자가 있기를 바랍니다.

@amcasey 이 문제 를 조사하기 위해

이 시점에서 우리는 라이브러리의 나머지 부분에 대한 신속한 피드백을 위해 JSS에서 약간의 유형 안전성을 교환하게 되어 기쁩니다. 때로는 Typescript 서버가 코드 변경 사항을 따라잡기까지 8-10초의 대기 시간이 소요됩니다.

3회 평균을 내더라도 데이터는 매우 시끄럽습니다. 그러나,에서 런타임에 띄게 하락이있을 나타납니다 https://github.com/microsoft/TypeScript/commit/ad322a561a301ae357da051b9221b2222c13be36 에서 눈에 띄게 증가 (대략 이전 수준으로 돌아 가기) https://github.com/microsoft/TypeScript를 /commit/480b73915fdd805952fd355e4cf3e1bc803e0878 그리고 https://github.com/microsoft/TypeScript/commit/c5e6d95e9330048a 의 특정 스파이크를 포함하여 (나에게 너무 균일하게 보이고 환경 요인이 의심되지만) 일반적인 상승 추세 나는 일반적인 상승 추세를 확인하기 위해 몇 가지 테스트를 더 실행할 때까지 처음 두 가지에 집중할 것입니다(모든 커밋이 어떻게 균일하게 악화될 수 있습니까?).

상승 추세는 면밀한 조사를 받고 있으며 그 원인이 무엇인지 전혀 모릅니다. 아마도 개별 감속이 너무 가까워서 소음으로 인해 단일 곡선처럼 보일 수 있습니다.

커밋당 최대 10개의 실행을 올렸고 이제 경사 영역에 4개의 뚜렷한 회귀가 있습니다. :웃다:

https://github.com/microsoft/TypeScript/commit/26caa3793e310e271ddee8adc1804486e5b0749f(~700ms )
https://github.com/microsoft/TypeScript/commit/250d5a8229e17342f36fe52545bb68140db96a2e(~500ms )
https://github.com/microsoft/TypeScript/commit/7ce793c5b8c621af5ce50af0ca3958c7bd6541bf(~1300ms )
https://github.com/microsoft/TypeScript/commit/28050d5c47c6cd7627555f12cf13b1062f80322a(~400ms )

(회귀가 시작되기 전의 총 시간은 ~33초였습니다.)

기대치를 조금 낮추기 위해: 이러한 회귀 중 일부는 가치 있는 추가 수표로 판명될 가능성이 매우 높으며 이러한 수표를 모두 무료로 얻을 수 있다 하더라도 여전히 20%만 할인됩니다. ".

편집: 링크를 업데이트했습니다. 시간을 거슬러 올라가고 있었기 때문에 혼란스러워서 각 회귀 _before_ 병합에 플래그를 지정했습니다.

@eps1lon 이 끝에서 누군가 @ts-ignore 을 제거하는 것이 도움이 될 수 있다고 제안했습니다. 기본적으로 오류가 감지되면 사용자의 최우선 순위는 오류에 대한 좋은 정보를 얻는 것으로 가정하므로 많은 추가 작업이 수행될 수 있습니다. 해당 정보가 이후에 삭제되면( @ts-ignore 인해) 그 시간은 낭비됩니다. (불행히도 오류를 감지할 필요가 없다는 것을 감지하는 것은 간단하지 않습니다.) 대안 전략은 컴파일러가 불평을 멈출 때까지 명시적 유형 주장( any )을 추가하는 것입니다.

@eps1lon 이 끝에서 누군가 @ts-ignore 을 제거하는 것이 도움이 될 수 있다고 제안했습니다.

docs/ 에서 한 번만 사용했습니다. 나는 만일의 경우를 대비하여 어쨌든 그것을 제거했다: #19504

솔직히 말해서 @ts-ignore 이 경우에는 안티 패턴인 것처럼 들립니다. 어떤 종류의 오류가 있는지와 같은 유용한 정보를 제공하지 않을 뿐만 아니라 성능 병목 현상도 발생합니다.

내가 말할 수 있는 한 @ts-ignore 는 유형 검사 중인 .js 파일에서만 유용합니다.

흠, PR 개선 오류 메시지가 성능을 저하시키는 이유를 거의 확실히 설명하지 못합니다. 그래도 확실히 개선된 것 같습니다. 😄

성능을 회귀하는 변경 사항에 대한 버그:
https://github.com/microsoft/TypeScript/issues/36562
https://github.com/microsoft/TypeScript/issues/36564
https://github.com/microsoft/TypeScript/issues/36565
https://github.com/microsoft/TypeScript/issues/36566
https://github.com/microsoft/TypeScript/issues/36567

공정한 경고: 이들 중 일부는 가치가 있다고 판단될 가능성이 높습니다.

저는 TypeScript의 세계, 특히 JS 스타일 솔루션과 관련하여 매우 익숙하지만 지난 한 달 동안 이 스레드를 조용히 따라갔고 잠재적인 해결 방법에 대한 사람들의 생각을 듣고 싶었습니다. 적어도 단기적으로는.

나는 일부 사용자(나 자신이 하나임)가 내장된 스타일링 시스템을 많이 사용하지 않거나 완전히 피한다고 가정합니다. 나는 주로 일반 CSS 또는 Sass에 훨씬 더 익숙하고 JS 스타일링 시스템을 효과적으로 사용하는 방법을 파헤칠 시간이 없었기 때문에 주로 그렇게 했습니다. 나는 나만의 클래스 이름을 만들고, 별도의 스타일시트 파일을 작성하고, React 구성 요소 내부의 클래스 이름을 사용하고 계속하는 것을 선호합니다. 기본적으로 저는 일반 HTML을 작성하는 것처럼 스타일을 지정합니다.

즉, 스타일링 시스템의 값비싼 부분에 대한 유형 검사를 해제하는 플래그를 추가하는 것이 가능/실용적입니까( type CSSProperties = any 와 같은 작업을 조건부로 수행하여)? 스타일 시스템을 사용하는 사람과 사용하지 않는 사람의 수에 대한 통계를 알지 못하지만 실제로 큰 피해를 줄 수는 없다고 생각합니다. , 최소한 한 사용자 세그먼트의 성능을 향상시키는 빠른 방법이 될 것입니다.

일반적인 아이디어를 언급하고 싶었습니다. 마음껏 쏘세요. :약간_웃는_얼굴:

@embeddedt 일반적으로 any 로 명시적으로 표시하는 것은 해당 기호에 대한 유형 검사를 비활성화하는 좋은 방법입니다. 그렇긴 하지만 이전 선언을 방해할 수 있는지, 아니면 제안한 대로 중복 선언 문제를 피하기 위해 컴파일러 지원이 필요한지 기억나지 않습니다.

새로운 수치(다른 기계, 다른 시간 측정법):

| 버전 | 총 시간 |
|-|-|
| 3.5.3 | 32.5초 |
| 3.7.5 | 35.9초 |
| 마스터 | 29.9초 |

위에 게시한 문제 중 일부는 여전히 열려 있지만 기본적으로 3.5 perf(이 벤치마크의 경우)로 돌아갑니다. 분명히 우리가 원하는 것보다 훨씬 느리지만 다음 변경 사항은 material-ui 쪽에 있을 가능성이 높습니다.

테스트 스위트에서 3.8.1을 테스트했으며 3.2.4를 사용하는 이전 버전만큼 빠른 것 같습니다(3.7은 상당히 느림).

솔직히 말해서, 나는 우리가 새로운 기능을 포기하지 않고 얼마나 많은 성과를 되찾을 수 있었는지 믿을 수 없습니다. :smile: 좀 더 여유가 있을 수 있다고 생각합니다(예: https://github.com/microsoft/TypeScript/pull/36754). 하지만 가장 영향력 있는 변경은 CSSProperties 유형의 단순화일 것이라고 생각합니다. 당신은 그들과 함께 놀 기회가 전혀 없었습니까? 적어도 일부 사용자(예: @embeddedt)는 성능 향상에 대한 대가로 일부 유형 검사를 기꺼이 포기할 것 같습니다.

적어도 일부 사용자(예: @embeddedt)는 성능 향상에 대한 대가로 일부 유형 검사를 기꺼이 포기할 것 같습니다.

TS 팀의 누군가가 최근에 더 엄격한 유형을 원하는 모든 사용자에게 더 느슨한 유형을 원하는 사용자가 있다고 트윗하지 않았습니까? :웃다:

나에게 그것은 유형 검사에 관한 것이 아닙니다(브라우저 devtools는 CSS를 검사하는 훨씬 더 나은 기능을 가지고 있습니다). 자동 완성 기능을 사용하는 것이 더 중요합니다.

나는 다른 "버전"을 가지고 놀고 그들이 어떻게 하는지 볼 것입니다.

@amcasey CSSProperties (styled-components에서 CSSObject라고 함)의 재귀적 특성이 주요 문제라고 생각하지 않습니다. 그렇지 않으면 그들의 성능이 우리만큼 나쁠 것입니다. https://github.com/eps1lon/mui-types-perf/pull/6 및 벤치마크 로그를 참조 하십시오 .

우리가 수행하는 "과부하"의 양에 더 많은 문제가 있을 수 있습니다. styled-components 는 썽크 버전과 각 속성이 썽크가 되는 것을 허용하는 동안 정적 개체만 허용합니다. 확실하지 않습니다.

유형 서명을 단순화하고 싶지만(개발자가 이해하기 쉬운 IMO이기 때문에) JSS 구현과 일치하도록 명시적으로 요청받았습니다. 이제 지원하므로 쉽게 롤백할 수 없습니다. 특히 이득이 20% 영역에 있는 경우. 나는 그것이 파손을 정당화한다고 생각하지 않습니다.

유형을 조건부로 덜 정확하게 만들 수 있습니까(사용자 설정에 따라)? 이는 기존 코드를 손상시키지 않아야 하며(기본적으로 설정이 해제될 수 있기 때문에) 복잡한 유형이 필요하지 않은 나와 같은 사용자가 성능 향상을 빠르게 확인할 수 있습니다.

복잡한 유형이 필요하지 않은 사용자가 성능 향상을 빠르게 확인할 수 있습니다.

눈에 띄는 차이를 얻을 수 있는지조차 확인되지 않았습니다. 나는 15%의 성능 승리를 보았지만 이것이 인식 가능한지 의심스럽습니다.

내가 볼 수있는 "사용자 설정"은 설치할 때 패키지를 패치하는 것입니다. 여러 버전의 타이핑을 유지할 수 있는 대역폭이 없습니다.

@eps1lon 죄송합니다. 제 질문이 명확하지 않은 것 같습니다. 나는 CSSProperties 가 괜찮다고 생각합니다. (물론 더 작으면 더 빠를 것입니다) - 실제로 https://github.com/mui-org 에서 하위 유형을 단순화할 여지가 있기를 바랐습니다. 이 유형 을 any 변경 하면 완료 횟수가 줄어들 것입니까?

편집: 내 상자에서 이렇게 하면 docs 프로젝트를 15% 더 빠르게 컴파일할 수 있지만(29.7초에서 25.5초로) 편집 환경에 미치는 영향을 모르겠습니다.
편집 2: 실제로 유형의 재귀 부분에서 접기를 포기하면 BaseCreateCSSProperties 사용할 수 있으며 다른 속성은 any 유형을 갖게 됩니다(즉, CSS 속성의 실제 유형).
편집 3: 편집 2는 과도한 속성 검사로 인해 작동하지 않습니다(즉, 임의의 속성 이름은 개체 리터럴에서 허용되지 않음).

완료 대 유형 검사에 대한 귀하의 요점은 일부 유형 작성자가 그렇게 느낄 수 있다는 가설이 있었기 때문에 매우 흥미로웠습니다. @DanielRosenwasser "a" | "b" | string 패턴을 수용하기 위해 이와 같은 작업을 수행한 것 같습니다.

또한 styled-components 에는 밀접하게 관련된 검사기 성능 문제가 있습니다.

유형을 보다 정확하게 지정할 수 있는 것과 관련하여 https://github.com/microsoft/TypeScript/issues/36782를 제출했습니다

emotion 이(가) 같은 보트에 있는 것 같습니다.

오늘 내 프로젝트에 Material UI( 4.9.4 )를 추가하기 시작했는데 속도가 너무 느려서 내 프로젝트에서 사용할 수 없을 것 같습니다. withStyles() 사용하여 사용자 정의된 간단한 <Slider/> 구성 요소를 추가했습니다.

우리는 IDE의 즉각적인 TypeScript 피드백에서 때때로 5-10초처럼 느껴지는 것으로 이야기하고 있습니다(지금 Material UI와 상호 작용하지 않는 코드 부분의 경우 - 구성 요소). 이러한 유형에 대해 뭔가 크게 잘못되었을 것입니다(또는 너무 복잡합니다). @amcasey 가 좋은 조사를 하고 있는 것 같습니다.

지금은 @material-ui 대한 모든 TypeScript 항목을 최소한 제외할 수 있는 방법을 찾으려고 합니다(기본적으로 전체 모듈 any ). 하지만 TypeScript는 그렇게 쉽게 만들지 않는 것 같습니다.

@lostpebble withStyles 가 아닌 다른 것을 사용하여 슬라이더를 사용자 정의할 때도 같은 일이 발생합니까(예: CSS 모듈)?

@lostpebble 현재 특정 유형 집합을 제외하는 지원되는 방법이 없습니다. 당신이 정말로 정말로 원한다면 실험할 것은 경로 매핑이 될 것입니다. "@material-ui/*": ["simplemui"] 와 같은 경로 매핑을 시도한 다음 다음을 포함하는 simplemui.d.ts 를 만들 수 있습니다.

declare const x: any;
export = x;

그러면 모든 material-ui 유형이 효과적으로 any 됩니다. 이것은 확실히 해킹이며 내가 추천할 수 있는 것은 아니지만 편집 경험을 차단할 수 있습니다.

나는 우리가 (30% 영역에서) 좋은 개선을 했다고 생각하지만, 지금 우리가 할 수 있는 일은 타이핑을 더 느슨하게 만드는 것뿐인 것 같습니다.

이것은 어떤 잘못된 코드가 유형 검사기에 의해 수락될 수 있는지와 같은 구체적인 제안이 절대적으로 필요합니다. 그런 다음 벤치마킹하고 이것이 의미 있는 움푹 들어간 곳인지 확인해야 합니다.

의도적으로 도입된 회귀는 라이브러리 소비자에게 이것을 설명해야 하고 전반적으로 상당히 스트레스가 많기 때문에 유지 관리자에게 많은 작업을 추가한다는 것을 이해해야 합니다.

따라서 누군가가 실행 가능한 정보를 가지고 있지 않는 한 이것은 현재 나에게 우선 순위가 아닙니다. 그렇지 않으면 아주 적은 수익에 너무 많은 시간을 투자해야 합니다.

makeStyles(theme => createStyles(...)) 경우 Record<ClassKey, any> 에서 createStyles(...) 거의 ~절반~ (내 코드와 컴퓨터에서 약 ~1200ms -> 750ms~ 1400ms → 1100ms) encodedSemanticClassifications-full: elapsed time 는 tsserver 로그에 표시됩니다(비용이 많이 드는 작업은 아니지만 아마도 유형 검사가 완료되기를 기다리는 것 같습니다).

export default function createStyles<ClassKey extends string, Props extends {}>(
  styles: StyleRules<Props, ClassKey>,
): Record<ClassKey, any>;

createStyles(...) 는 스타일 구조를 검사하므로 makeStyles의 대규모 통합 인수 유형 대 createStyle의 대규모 통합 반환 유형에 대한 유형 검사를 건너뛸 수 있습니다.

~(전체 makeStyles 코드 주석 처리: 650ms)~

@ypresto createStyles 는 const 어설션이 없는 typescript 버전에만 필요합니다. 코드베이스에서 { display: 'block' as const } 를 사용할 수 있으면(ts >= 3.4) createStyles .

@eps1lon 우리는 그것을 알아차리고 docs 에서 전환을 시도했지만 결과는 인상적이지 않았습니다.

@eps1lon with const 및 createStyles , IntelliSense는 더 이상 컨텍스트 인식 후보를 표시하지 않습니다 .cry :

@ypresto 그래야 합니다. 예제 코드 스니펫이 있습니까?

@암케이시

외부 개체 또는 속성에 as const 를 추가하면 효과적으로 종료됩니다. 나는 모든 부동산에 그것을 배치하고 싶지 않습니다.

const useStyles = makeStyles(theme => ({
  root: {
    // no IntelliSense
  }
} as const))

또한 createStyles가 없으면 문자열 완성에 약간의 제한이 있습니다.

const useStyles = makeStyles(theme => ({
  root: {
    direction: '|', // no IntelliSense at | (works with createStyles)
    direction: | // IntelliSense works at |
  }
}))

@ypresto "죽인다"는 말은 " createStyles 와 같은 방식으로 작동하게 함"을 의미합니까?

어디에나 두는 것은 힘들지만 createStyles 어디에나 두는 것보다 더 끌리는 것은 없습니다.

@amacleay 나는 kills IntelliSense : 기도:.

죄송합니다, 귀하의 의견을 놓쳤습니다. 한 번 해보겠습니다.

이유는 모르겠지만 흥미롭게도 이것은 1100ms → 750ms입니다.

 export const DropArea: React.FC<CardProps & {
   active?: boolean
   description: string
   icon?: React.ReactNode
-}> = ({ active, description, icon, children, ...props }) => {
+}> = ({ children, ...props }) => {
   const classes = useStyles()
+  const active = false
+  const icon: React.ReactNode = null
+  const description = ''
   return (
     <Card {...props} className={clsx(classes.root)} variant="outlined">

FC에서 CardProps & 를 제거해도 거의 동일한 결과입니다. 아마도 CardProps가 큰 HTMLAttributes를 확장하는 PaperProps를 확장하기 때문일 것입니다.

업데이트 및 중요: CardProps를 HTMLAttributes<HTMLDivElement> 교체하면 시간도 단축되는 것으로 나타났습니다(측정되지 않음).

마지막으로 가장 큰 것을 찾았습니다. 750ms → 130ms:

두 개의 타이포그래피에서 style={...} 제거.

-<Typography variant="subtitle2" component="div" noWrap style={{ width: '26ch' }}>...</Typography>
+<Typography variant="subtitle2" component="div" noWrap>...</Typography>
-<Typography variant="caption" component="div" noWrap style={{ width: '20ch' }}>...</Typography>
+<Typography variant="caption" component="div" noWrap>...</Typography>

하지만 왜? <div> 같은 스타일을 추가해도 성능이 저하되지 않습니다. OverridableComponent 너무 복잡한거 아닐까요..?

(저는 TypeScript 3.8.3, @material-ui/core 4.9.1을 사용하고 있습니다)

Material-UI가 구성 요소의 로컬 스타일을 처리하는 AFAIK 방식은 React가 HTML 요소를 처리하는 방식과 다릅니다.

@embeddedt 유형 수준에서 div의 스타일 소품과 동일한 React.CSSProperties 해석됩니다.

@ypresto 정정합니다. 죄송합니다.

안녕하세요 여러분, 이에 대한 새 문제를 여는 것이 가치가 있는지 확실하지 않으므로 유형 정확성/성능과 관련이 있으므로 여기에 게시하겠습니다. 대신 문제를 열어야 하는지 알려주세요.
사용자 정의 글꼴을 추가 하기 위해
Type 'string' is not assignable to type 'FontFaceFontDisplayProperty'

csstype 2.6.9 입력이 유효하고 다른 속성은 정상이기 때문에 이상합니다(MUI 4.9.5 사용).

const sourceSansPro = {
  fontFamily: "'Source Sans Pro'",
  fontStyle: "normal",
  fontDisplay: "swap", // won't work
  fontWeight: 400,
  src: `
    url('/static/fonts/Source_Sans_Pro/SourceSansPro-Regular.ttf') format("truetype")
  `
};

테마 속성:

  overrides: {
    MuiCssBaseline: {
      "@global": {
        "@font-face": [sourceSansPro]
      }
    }

유형은 type FontFaceFontDisplayProperty = "auto" | "block" | "fallback" | "optional" | "swap";

@eric-burel 이것은 typescripts의 자동 유형 확장 문제입니다. 노력하다

- fontDisplay: "swap", // won't work
+ fontDisplay: "swap" as "swap",

덕분에 작동하고 "유형 확장"이라는 새로운 개념을 배웠습니다 :) 예를 들어 fontStyle 가 영향을 받지 않는다는 것이 이상합니다. 열거형으로 정의된 유일한 CSS 속성이 아니라 처음으로 이것을 쳤을 때 .

편집: 좋아, 잘 문서화되어 있습니다: https://material-ui.com/guides/typescript/#using -createstyles-to-defeat-type-widening

마지막으로 가장 큰 것을 찾았습니다. 750ms → 130ms:

두 개의 타이포그래피에서 style={...} 제거.

-<Typography variant="subtitle2" component="div" noWrap style={{ width: '26ch' }}>...</Typography>
+<Typography variant="subtitle2" component="div" noWrap>...</Typography>
-<Typography variant="caption" component="div" noWrap style={{ width: '20ch' }}>...</Typography>
+<Typography variant="caption" component="div" noWrap>...</Typography>

하지만 왜? <div> 같은 스타일을 추가해도 성능이 저하되지 않습니다. OverridableComponent 너무 복잡한거 아닐까요..?

(저는 TypeScript 3.8.3, @material-ui/core 4.9.1을 사용하고 있습니다)

이것이 빌드 시간에 영향을 미치거나 Intellisense가 유용하는 데 걸리는 시간에만 영향을 미친다는 것을 알았습니까? 빌드 문제(메모리 부족)가 발생하고 일부 TS 코드에는 구성 요소에 많은 style={someStyle} 설정되어 있습니다. 그것이 우리 문제의 일부인지 궁금합니다.

@yatrix7 , 일반적으로 말하자면 이러한 긴 검사 시간이 빌드 및 편집기 응답 시간에 모두 영향을 미칠 것으로 예상합니다.

나는 현재 이것을 조사하고 있는 사람이 있습니까? 이전 버전 업그레이드에서 typescript 유형 확인 시간과 관련하여 몇 가지 개선 사항이 있다는 것을 알고 있습니다. 그러나 여전히 느립니다.
이것에 대해 스스로 조사하는 것을 꺼리지 않을 것입니다.

이것에 대해 스스로 조사하는 것을 꺼리지 않을 것입니다.

정말 대단합니다. 현재 작업할 수 있는 실행 가능한 항목이 없습니다. 따라서 병목 현상에 대한 포인터를 주시면 감사하겠습니다.

조사에 도움이 되도록 현재 몇 가지 벤치마킹을 추가했습니다. https://github.com/mui-org/material-ui/pull/22110

@FabianKielmann TS 쪽에서 나는 머티리얼 UI에 적용할 수 있을 만큼 곧 성숙하기를 바라는 성능 조사 도구를 작업해 왔습니다.

이것에 시간을 할애한다면 https://github.com/microsoft/TypeScript/issues/38583 과 같은 것을 시도해 볼 수도 있습니다