Material-ui: パフォーマンスを向上させるためにタイピングを簡略化できますか？

私はmaterial-uiタイプに精通していませんが、これらの質問に答えようとします。

1. はい、実際のWeb標準で宣言されているすべてのcssプロパティの完全なサポートは便利です。
2. a）私たちの場合、2を超える深さを使用することはありませんが、このような場合はかなり可能です。
   `` `typescript
   const styles =（テーマ：テーマ）=>
   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. [...]
   これらのバッグ自体は再帰的ですか、それとも追加のレイヤーが1つだけですか？

使用しているCSS-in-JSソリューションを確認する必要があります。 技術的には、CSSのメディアクエリは再帰的になる可能性があります。 私はこの再帰性を削減し、レポートを受け取るかどうかを確認したいと思います。 技術的にネストされたメディアクエリは、 and演算子を使用してフラット化できます。 ただし、2つのレベルに制限する必要があります。1つはメディアクエリ用で、もう1つは疑似セレクター用です。 これはまだタイプチェックされたIMOである必要があります：

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

これはあなたが@oliviertassinariを書いているのを見たものですか？

1. [...]
   CSSProperties-または（props：Props）=> CreateCSSProperties、これは事実上ダブルレイジーであるため理解できませんでした。プロップを1回渡して、CreateCSSPropertiesを取得してから、もう一度個々のプロパティを取得する必要があります。 なぜ「ダブルサンク」なのですか？

引数自体がプロパティバッグではなく関数である場合は、テーマが必要です。 スタイルは、2つの異なる種類のプロパティバッグに依存する可能性があります。テーマ（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が提供するメリットに対して高すぎることをまだ実証していません。 ただし、メリットがよくわからない可能性もあるので、もっと聞いてみてください。

これが使用される1つのケースがあります：

検討

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どのようなスタイルのバッグが渡されるかを確認する必要があります。 スタイルバッグで使用されている小道具の種類を推測するためのヘルパーがすでにいます。 スタイルバッグが静的である場合、つまりTSが{}タイプを推測する場合。 次に、 IsEmptyInterfaceを使用して小道具の推定タイプを確認し、一方のブランチには0パラメーターの呼び出し署名を使用し、もう一方のブランチには、推定小道具タイプに等しい1パラメーターの呼び出し署名を使用します（ StylesRequirePropsおよびStylesHook参照してください。

つまり、 useStaticStyles({})またはuseStaticStyles(null as any)と書く必要はありuseStaticStyles({}) 。 https://github.com/mui-org/material-ui/issues/14018を閉じるためにhttps://github.com/mui-org/material-ui/pull/14019で導入されました

この「機能」の問題は、上級ユーザーが理由を理解していれば、 null as anyを使用しても問題がないことです。 たぶん、空のオブジェクトを渡すことさえ、必要ではないのに大丈夫です。 ただし、Material-UIまたはTypeScriptに慣れていない場合は、非常に混乱し、イライラします。 特にスタイリングのほとんどはとにかく小道具に基づいていないので。

ほとんどの場合、タイプチェッカーはスタイリングソリューションで占められているようですか？ コンポーネントの呼び出し署名、つまり、ほとんどの場合にどの小道具を使用できるかを期待していました。

より多くのリポジトリをクロールして、 withStylesまたはmakeStyles使用状況を具体的に調べることができます。 これまでのところ、小道具の使用法だけを見てきました。

これはあなたが@oliviertassinariを書いているのを見たものですか？

@ eps1lonコードベースにこのネストがいくつか発生しています（たとえば、 <strong i="8">@media</strong> (hover: none) ）。 ただし、コアコンポーネントではそれほど頻繁ではありません。 同じユーザーランドだと思います。 それは間違いなくトレードオフの一部である可能性があります。

@beholderrk

1. 私は同じくらい考えました、しかし私が尋ねたほうがよいと思いました。
2. a）深さ2は表現可能である必要があります-深さ1よりも少しだけ重複があります。
   b）頭を悩ませるのにかなりの時間がかかりました。テキストではなく、直接説明できればと思います。 基本的に、インデックスシグネチャは、すべてのプロパティが同じタイプであることを示しています。 これは、それらすべてで機能するタイプを指定している場合にのみ機能します。 これを行う1つの方法は、すべてのプロパティタイプの和集合BaseCSSProperties[keyof BaseCSSProperties]することです。そうすると、すべてのプロパティに互換性のあるタイプがあることは事実です。 たとえば、CSSで使用できるプロパティがname: stringとwidth: numberます。 両方のプロパティで機能するインデックス署名を指定する1つの方法は、すべてのプロパティがstring | numberあると言うことです。 それは素晴らしいことではありません- nameがnumber widthなることはなく、 stringなることもありません-しかし、それは機能します。 本当の問題は、あなたが望むものを実際に表現できないことです（少なくとも、私たちが判断できた限りでは、それを行う「巧妙な」ハックがあるかもしれません）。 あなたは実際にあなたのタイプがname: string 、 width: numberまたはx: CSSProperties含んでいると言いたいです、ここでxはnameまたはwidth -欠けているのは「以外のもの」です。 それがもう少し明確になることを願っています。
3. @ eps1lonがこれについて何か言いたいことがあるように聞こえましたが、私はまだ彼の応答を解析しています。

正常なベースラインは非常に役立ちます。 あなたはたまたまリンクを持っていますか？
編集：それを見つけました。

@ eps1lon会話に参加

1. ここでは議論はありません-会話全体が短絡してしまうので、早めに質問すると思いました。
2. 2つのレイヤーは実行可能のようです（タイプはまだほとんど役に立たないという注目すべき警告があります）。 何かをドラフトできるかどうか確認します。
3. 私の文脈の欠如で、テーマと小道具が異なっていることは明らかではありませんでした。 もしそうなら、その構造は理にかなっています。 明確にしていただきありがとうございます。

isEmptyInterfaceに関して、プロパティパラメータを（たとえば） useStaticStylesオプションにすることはできますか？ 発信者が期待どおりにそれらを省略できるという意味では、それほど正確ではありませんが、タイプチェックの方がはるかに安価です。 私が言ったように、私はあなたのために数字や何かを持っていません-それは私の側の単なる憶測です。

2（b）についてどう思いますか？ そのタイプは、基本的にすべてのプロパティ名が受け入れられ、戻りタイプは多くのものの1つになる可能性があることを示しているため、あまり価値がないようです。

isEmptyInterfaceに関しては、プロパティパラメータを（たとえば）useStaticStylesをオプションにすることができますか？

最初に呼び出しシグネチャをオーバーロードして実験し、これが影響を与えるかどうかを確認したいと思います。 次に、常にオプションにすることで、音を少なくしてみます。 ほとんどすべてのユースケースで1回しか呼び出されないため、通常よりも音を少なくする方が安全だと思われます。そのため、間違いを1回だけ行う可能性が高く、すぐに表示されます。 それが私たちに多くのパフォーマンスをもたらさなければ、それを売るのは難しいでしょう。 元の問題用に作成されたリポジトリ（https://github.com/microsoft/TypeScript/issues/34801#issue-514055289）を使用します。

2（b）についてどう思いますか？ そのタイプは、基本的にすべてのプロパティ名が受け入れられ、戻りタイプは多くのものの1つになる可能性があることを示しているため、あまり価値がないようです。

誤ってスキップしました。 IsEmptyInterfaceの実験の後でそれを見ていきます。

@ eps1lon完全に同意します-それを排除することが実質的なパフォーマンスの勝利ではない場合は、 isEmptyInterface維持します。

＃19320では、関数のオーバーロードが同じことを達成したいくつかの複雑な条件型を取り除きました（ IsEmptyInterfaceとブール論理型を削除しました）。 コードが少ない以外に、あまり得られなかったようですが。

現在、TS3.2.4と3.7.4の間を行ったり来たりしていることを付け加えたいと思います。 私たちのタイプのテストスイートは、3.2.4と比較して3.7.4で50％遅く実行されます（〜90s対50s）。

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のエラーが発生します。 私は何が間違っているのですか？ プロファイリングの目的で、再現を1回のtsc呼び出しにまで下げることは非常に役立ちます。

@amcasey yarn typescriptはコンパイルではなく、型のテストです。 DefinitelyTypedリポジトリで使用されているものと同様の設定を使用しています。 packages/*内のTypeScriptファイルは、ほとんどの場合、合格または不合格のいずれかであるステートメントの集まりであり、 $ExpectErrorキャッチします。

skipLibCheck: trueとnoEmit: trueを./docs/tsconfig.json追加した後、 yarn workspace docs run tsc -p tsconfig.jsonを介してドキュメントでtscを使用するのが最良の「実際の」テストケースだと思います。 ./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明確にしてくれてありがとう。 tslintが遅くなったことにわくわくしていませんが、一度に1つの変数に焦点を当てたいと思います。 提案したドキュメントビルドをさまざまなバージョンのtypescriptで実行し、何かが飛び出すかどうかを確認します。 ありがとう！

この設定は完璧です。 チェック時間が3.3と3.4の間で2倍になっています。

| バージョン| 時間を確認する|
|-|-|
| 3.2 | 16.71秒|
| 3.3 | 16.79s |
| 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これらの数値は、各バージョンでの1回の実行によるものであるため、おそらくかなりのノイズがあります。 しかし、私は掘り下げて、何かを見つけることができるかどうかを確認します。

Linux VMでやり直したところ、3.7は3.5よりも一貫して20〜25％遅くなりました。

同じビルドの連続実行は約5％変動し、3.5と3.6の間または3.6と3.7の間の差はわずか約10％であるため、これを二分するのは非常に難しいことが証明されています。

私が気付いた疑わしいことの1つは、 styled-componentsがTS> = 3.7に対して個別の.d.tsファイルを提供するため、比較がリンゴとリンゴではない可能性があることです。

驚いたことに、新しいstyled-componentsタイプの方が高速であるように見えます。 ただし、リンゴとリンゴを比較すると、調査が容易になります。

賢い解決策が思いつかなかったので、マージによるコンパイル時のマージをプロットして、スパイクを探します。 明日は数字が欲しいです。

@amcaseyこれを調査するためにあなたの努力に感謝します！ TSチームのメンバーとマテリアルUIが一緒に機能しているのを見るのは本当に素晴らしいです。 私はこのGithubの問題に遭遇し、Material UIでのエディターのエクスペリエンスが非常に遅い理由を理解しようとしました（2つのプロジェクトで使用しています）。 VsCode内のインテリセンスとユーザビリティにかなり大きな影響が見られていることを明確に確認できます。

この時点で、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/c5e6d95e930048a033868d72440a9296904a33ecでの特定のスパイクが含まれ

上昇傾向は精査に耐えており、何がそれを引き起こす可能性があるのか​​私にはわかりません。 たぶん、離散的な減速は非常に接近しているので、ノイズがそれらを単一の曲線のように見せます。

コミットごとに最大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％の割引しか受けられません。 "。

編集：リンクを更新しました。 私は時間を遡っていたので、混乱し、各回帰の_前_にマージのフラグを立てました。

@ eps1lonこの@ts-ignoreを削除すると役立つかもしれないと提案しました。 基本的に、エラーが検出された場合、ユーザーの最優先事項はエラーに関する適切な情報を取得することであると想定されるため、多くの追加作業が行われる可能性があります。 その後、その情報が削除された場合（ @ts-ignore ）、その時間は無駄になります。 （残念ながら、エラーを検出する必要がないことを検出するのは簡単ではありません。）別の戦略は、コンパイラが文句を言うのをやめるまで、明示的な型アサーション（ anyを含む）を追加することです。

@ eps1lonこの@ts-ignoreを削除すると役立つかもしれないと提案しました。

docs/使用は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ソリューションのスタイリングに関してはまったく新しいですが、先月このスレッドを静かにフォローしていて、潜在的な回避策についての人々の考えを聞いて興味がありました。少なくとも短期的には。

一部のユーザー（私自身も1人）は、組み込みのスタイリングシステムを多用しないか、完全に回避していると思います。 これは主に、プレーンなCSSまたはSassに精通していて、JSスタイリングシステムを効果的に使用する方法を掘り下げる時間があまりないためです。 私は自分のクラス名を作成し、別のスタイルシートファイルを作成し、Reactコンポーネント内でクラス名を使用して続行することを好みます。 基本的に、私はプレーンHTMLを書いているかのようにスタイルを設定します。

そうは言っても、スタイリングシステムの高価な部分の型チェックをオフにするフラグを追加することは可能/実用的ですか（おそらくtype CSSProperties = anyようなことを条件付きで行うことによって）？ スタイルシステムを使用している人と使用していない人の数の統計はわかりませんが、実際にはそれほど害はないと思います（そのフラグが設定されたタイピングをテストするためにチェックが追加された場合） 、そしてそれはユーザーの少なくとも1つのセグメントのパフォーマンスを改善するための迅速な方法です。

一般的な考え方に言及したかっただけです。 お気軽に撃墜してください。 ：slightly_smiling_face：

@embeddedt一般的に、何かをanyとして明示的にマークすることは、そのシンボルの型チェックを無効にする良い方法です。 そうは言っても、前の宣言を単に壊すことができるのか、それとも、あなたが示唆するように、重複した宣言の問題を回避するためにコンパイラのサポートが必要なのかを思い出せません。

新しい数値（異なるマシン、異なる時間メトリック）：

| バージョン| 合計時間|
|-|-|
| 3.5.3 | 32.5秒|
| 3.7.5 | 35.9秒|
| マスター| 29.9秒|

上記で投稿した問題のいくつかはまだ未解決ですが、基本的に3.5パフォーマンスに戻っています（このベンチマークの場合）。 明らかに、それでも私たちが望むよりもはるかに遅いですが、次の変更のバッチはマテリアル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と相互作用していないコードの部分については、使用するファイルでの完全なTypeScriptの速度低下）コンポーネント）。 これらのタイプ（または、非常に複雑なタイプ）には、何かが大幅に間違っている必要があります。 @ amcaseyがいくつかの適切な調査を行っているようです。その

少なくとも今のところ@material-uiすべてのTypeScriptのものを除外できる方法を見つけようとしています（基本的にモジュール全体をany ）-しかし、TypeScriptはそれを十分に簡単にできないようです。

@lostpebble withStyles以外のものを使用してスライダーをカスタマイズしても同じことが起こりますか？CSSモジュールなどですか？

@lostpebble現在、特定のタイプのセットを除外するためのサポートされている方法はありません。 本当に、本当にやりたいのであれば、実験するのはパスマッピングです。 "@material-ui/*": ["simplemui"]ようなパスマッピングを試してから、次を含むsimplemui.d.tsを作成できます。

declare const x: any;
export = x;

これにより、すべてのマテリアル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のargument-type-of-massive-unionとcreateStylesのreturn-type-of-massive-unionの型チェックをスキップできます。

〜（そしてmakeStylesコード全体をコメントアウトする：650ms）〜

@ypresto createStylesは、 constアサーションのないtypescriptバージョンにのみ必要です。 コードベースで{ display: 'block' as const }を使用できる場合（ts> = 3.4）、 createStylesを超えて使用します。

@ eps1lonそれに気づき、 docs切り替えを試みましたが、結果は印象的ではありませんでした。

@ eps1lonにconstあり、 createStylesがない場合、IntelliSenseはコンテキスト認識候補を表示しなくなります：cry：

@yprestoそうすべきです。 サンプルのコードスニペットはありますか？

@amcasey

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がPaperPropsを拡張し、PaperPropsが大きなHTMLAttributesを拡張するためです。

更新と重要： CardPropsをHTMLAttributes<HTMLDivElement>置き換えると、時間も短縮されることがわかりました（測定されていません）。

最後に、最大のもの、750ms→130msを見つけました。

2つのタイポグラフィから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がコンポーネントのローカルスタイルを処理する方法は、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これは、typescriptの自動型拡張に関する問題です。 試す

- 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を見つけました。

2つのタイポグラフィから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を使用しています）

これがビルド時間に影響するのか、それともインテリセンスが役立つのにかかる時間だけに影響するのかわかりましたか？ ビルドの問題が発生し（メモリ不足）、一部のTSコードのコンポーネントに大量のstyle={someStyle}設定されています。 それが私たちの問題の一部であるかどうか疑問に思います。

@ yatrix7 、一般的に言えば、これらの長いチェック時間は、ビルドとエディターの両方の応答時間に影響を与えると思います。

私は現在これを調べている人はいますか？ 以前のバージョンのアップグレードでは、typescriptタイプのチェック時間に関していくつかの改善があったことを私は知っています。 しかし、それでも遅いです。
これを自分で調べてもかまいません。

これを自分で調べてもかまいません。

それは素晴らしいでしょう。 現在、私たちが取り組むべき実用的な項目を認識していません。 したがって、ボトルネックへのポインタをいただければ幸いです。

調査に役立つように、今のところいくつかのベンチマークを追加しました： https ：

@FabianKielmann TS側では、私はパフォーマンス調査ツールに取り組んできました。これは、すぐに成熟して、material-uiに適用できるようになることを願っています。

これに時間を費やす時間があれば、 https：//github.com/microsoft/TypeScript/issues/38583のようなものを試すこともでき