Material-ui: [RFC] v5スタイリングソリューション💅

いくつかの修正があります：

Reactコミュニティは、概して、JSSを大規模に使用することに反対票を投じています。

代わりに、ReactコミュニティがJSSに投票しなかったことをお勧めします。 おそらく、他のソリューションと同様に「販売」されていなかったのでしょうか。

私たちは正しい馬に賭けませんでした。

私たちは唯一の馬に賭けました–それは1頭の競馬でした。 当時利用可能な他のソリューションのどれも、すべてのボックスにチェックを入れていませんでした。

感情は素晴らしいですね！ UIやスタイリングコンポーネントを構築するときに、オートコンプリートや、CSS-in-JSを使用した入力のすべての利点などのTSサポートを取得するのが大好きですが、それでも可能ですか？

最後のビットは私を手に入れました！ ベータフラグの背後でこれを行うか、いくつかの機能を開発することで支援したいと思います。

感情を使用するすべてのコンポジション（レンダリング時または定義時のコンポジション）は、要素の単一のクラスになります。
スタイル付きコンポーネントは、レンダリング時の構成に関してはこのようには機能しません（定義時の構成は単一のクラスに結合されます）。

また、テーマオブジェクトは同じままであることに注意しました。私の意見では、アプリケーションにテーマを設定するための絶対的な最善の方法です。 私は他に言うことは何もありません：驚いた：

M-UIのすばらしい作業に感謝します。 プロジェクトの方向性が大好きです。

より標準化されたスタイリングの方法に移行するのが道です。 チームとコミュニティが問題を解決することを私は知っています、そしてv5は-それの音によって-さらに素晴らしいものになるでしょう！ ：ロケット：

スタイル付きコンポーネントと感情の両方を使用したことがあるので、それらの間の移行は簡単で痛みがないことを確認できます。

+感情はよりタイプスクリプトにやさしい

Emotionのメンテナーとして話す-これは素晴らしいですね🚀

また、すぐに新しいメジャーをリリースできるようになるはずです。これは革命ではなく、いくつかのクリーンアップ、全体的な改善、内部のフック、TSタイプの改善（推論とパフォーマンスの向上）だけです。

ああ、そしてパーサーを書き直した！ これにより、EmotionおよびStyled-Componentsのいくつかのエッジバグが排除されます（現在、両方とも同じパーサーを使用しています）。 それはより小さくそしてより速いです。

重大な変更についてはどうですか？どのオプションがより重大な変更を導入しますか（もしあれば）？

それが違いを生むかどうかはわかりませんが、ベンチマークは感情やスタイルコンポーネントのbabelプラグインで行われましたか？ それらは物事をさらに最適化するのに役立ちます。

MUIが以前にスタイル付きで行くことを示していたのは私の理解でしたので、これは驚きです。 感情は素晴らしいライブラリだと思いますが、現在スタイルを使用している人が増えているため、感情に移行したくない場合は、適切なオプションを提供する方法を見つけることが重要です。

@ ee0pdt感情は、スタイルに非常によく似ています。 これは、スタイル付きコンポーネントよりもEmotionの選択肢全体の一部だと思います。 明らかなメリットがあり、移住債務はほとんどまたはまったくありません。

そして、開発者に選択肢を与えることによって両方をサポートすることについてのセクション全体があります。 それは進むべき道かもしれませんが、それでも、標準化はおそらく私たちの将来をさらに助けるでしょう。 完全な同時実行性があり、ラッパーコンポーネントがないことは、私にとって大きな問題です。 他の人がスタイル付きの何かを提供したいと思うかもしれないと私は思います、そしてそれは考慮されるべきです。 むしろ標準化を推し進めたい

styletron-reactが除外されたのはなぜですか？ 考慮されなかったメトリック全体、つまりメモリ消費量が除外されます。 デフォルトのstyletronエンジン（およびfela）はアトミックです。 少し遅くなりますが、多くのメモリを節約できます。 多くのreactページを見ても何も起こらず、しばらくすると1GBを超えることになります。少し心配です。 その後、ブラウザがフリーズします。

アトミックフレームワークを使用すると、各アトミック「クラス」がキャッシュされるため、コンポーネント全体で時間の経過とともにパフォーマンスがグローバルに向上します。 テストにも反映されていない可能性があります。

SSRをサポートしている限り、どちらにも満足

元のスタイルのコンポーネントの問題から投票を取り下げました：sweat_smile：-ストーリーブックを通じて感情を知ることを最初に学びましたが、 It will mean that all components styles need to be created using the styled API, which means for developers they will always have wrapper components if they need to re-style.切り替えました。

迅速なフィードバックをありがとうございました。 ここにいくつかのコメント/質問への回答があります。

重大な変更についてはどうですか？どのオプションがより重大な変更を導入しますか（もしあれば）？

styled-componentsとemotionを使用する@ sag1vは、処理する必要のある

// previosly
root: {
  contained: {
    '&$disabled': { // <-- this part will need to be transformed
      color: 'red',
    },
  },
  containedPrimary: {
    color: 'blue',
  },
}

// after
root: {
  contained: {
     '&.Mui-disabled': {
      color: 'red',
    },
  },
}

ただし、 emotionとstyled-components間のスタイル構文は同じであるため、違いはありません。

それが違いを生むかどうかはわかりませんが、ベンチマークは感情やスタイルコンポーネントのbabelプラグインで行われましたか？ それらは物事をさらに最適化するのに役立ちます。

@ hc-codersatlasいいえ、しかしパフォーマンスはとにかく上位数の間にあるので、それが違いを生むとは思わない。 グッドコールタフ！

styletron-reactが除外されたのはなぜですか？ 考慮されなかったメトリック全体、つまりメモリ消費量が除外されます。 デフォルトのstyletronエンジン（およびfela）はアトミックです。 少し遅くなりますが、多くのメモリを節約できます。 多くのreactページを見ても何も起こらず、しばらくすると1GBを超えることになります。少し心配です。 その後、ブラウザがフリーズします。

アトミックフレームワークを使用すると、各アトミック「クラス」がキャッシュされるため、コンポーネント全体で時間の経過とともにパフォーマンスがグローバルに向上します。 テストにも反映されていない可能性があります。

styletron-reactが除外された理由についての私のコメントは、それについて少し誤解を招くかもしれません。すぐにPRの説明を更新します。 パフォーマンスは良好ですが、styletronに関する最大の懸念はコミュニティです： https ：//www.npmtrends.com/styletron-react-vs-@emotion/core-vs-styled-components感情とstyled-componentsの両方過去6か月でダウンロード数が2000000を超えている場合、styletronは約15000です。

また、各クラス名には1つのスタイラールールしか含まれていないため、アトミックcssはオーバーライドで問題を引き起こす可能性があります。

すべてのファイルの上に以下のコードを追加したい感情を使用することにした場合、質問がありますか？
/ ** @jsx jsx * /
これはJSXプラグマであり、デフォルトではJSXプラグマはReact.createElementです。

感情的にcssプロパティを使用している場合は、これを追加する必要があります。 styled APIと通常のclassNameAPIの場合、これは必要ありません。

JSXプラグマの追加をスキップすることは可能ですが、追加のBabelセットアップが必要であり、ツールからのサポートが不十分です。たとえば、TSは、JSXプラグマを使用する場合ほど正確にCSSプロップをタイプチェックできません。 詳細については、 https ：

@mnajdovaありがとう。 特にstyletronの保証以上に、メモリ使用量がカバーされることを望んでいました。 ダウンロードやコミュニティに関しては、「唯一の」Uberはstyletronを使用しています:)なので、心配はいりません。 そもそも感情に投票した。

静的なスタイルを実際のcssクラスに変換できるbabelプラグインなどがあればクールでしょう。 compiledと呼ばれる同様のライブラリがすでにあります。 ほとんどのスタイルは現実的に静的です。

Felaを使用するには、 fela-plugin-rtl 、 fela-plugin-prefixerなどのプラグインのセットが必要です。これにより、パフォーマンスがさらに低下します（https://github.com/microsoft/fluentui/pull/12289）🐢そしてFelaの2倍の速度になることがあるため、おそらくEmotion（https://github.com/microsoft/fluentui/pull/13547）になります📦

私の唯一の懸念は、Emotionのcssものを使用する必要があることです。 それは私の経験に基づく大きな赤旗です。 私はそのようなものを大きなコードベースから削除しなければならず、面白くありませんでした。 どうして？ それは、長期的に解決する問題よりも多くの問題をもたらす抽象化だからです。

ほとんどの場合、 styled関数を使用しようとしますが、場合によっては、いくつかのクラスを生成するためのmakeStyles関数に非常に満足しています。

うまくいけば、これら2つのAPIに重大な変更はなく、 cssマクロを使用する必要はありません。

私の唯一の懸念は、Emotionのcssthingyを使用する必要があることです。

@yordis css小道具を使用することを強制されることは絶対にありません。 makeStylesとwithStyles使用法には、ある程度の変更があると思います。 うまくいけば、必要な変更の量は、インポートのcodemodにほとんど制限できます。 makeStylesまたはwithStyles使用されているアプローチは、感情の使用をサポートするのに実用的ではないと思います。したがって、これらのAPIの継続的なサポートは、別のパッケージを介して行われると思います（「 @ material-ui / core "にはJSS依存関係がなくなりました）、v5がリリースされた後はおそらく最小限のメンテナンスしか受けられません（ makeStylesとwithStyles何が起こるかについての詳細は特定されていませんそれでも、これは感情を持って前進することの意味についての私の推測にすぎません）。

👍感情を使用する選択。 回避styledのAPI styled-components私のチームは（も同様のサポートエモーションを選んだ理由の1つですstyledに加えて、APIをcss小道具を）。 現在、マテリアルUIスタイルのカスタマイズにEmotionを使用しており、非常にうまく機能します。 組み込みのサポートは、ケーキの上のアイシングになります。

これらの事実について：

多くの開発者は、styled-componentsを使用してMaterial-UIのスタイルをオーバーライドします。 エンドユーザーは、バンドルに2つのCSS-in-JSライブラリがあることに気付きます

並行モードをサポート
スタイル付きコンポーネント：部分的

スタイル付きコンポーネントが並行モードを完全にサポートしている場合、ほとんどの開発者がスタイル付きコンポーネント（JSSを除く）でMUIをオーバーライドしていることを考えると、より賢明な選択でしょうか？ 2つのcss-in-jsソリューションを含める必要がある場合、感情がバンドルサイズで小さくなるという点は重要ではありません。 そして、MUIの最も実用的なアプリケーションには、そのスタイルのオーバーライドが含まれていると思います。

私と私のチームがコンポーネントのスタイリングの主な方法としてEmotionを使用している場合、感情ライブラリに存在するいくつかの非効率性に遭遇しました。 そして、以下で説明するこれらの非効率性について皆さんはどう思いますか。

以下のEmotionStyledComponentを検討してください。

const StyledComponent = styled.div`
  ${({color}) => color && `color: ${color}`};
  display: flex;
  justify-content: center;
  align-items: center;
  background: teal;
  font-size: 20px;
  padding-top: 8px;
  padding-bottom: 8px;
  margin-top: 12px;
  margin-bottom: 12px;
  border: 1px solid grey;
`

カラープロップが変更されると、すべてのcssプロップ（ display: flex, justify-content, ..., border: 1px soild grey ）がコピーされた新しいcssクラスが生成されます。 これにより、各カラープロップに対してまったく同じcssプロップを持つcssクラスが生成されます。以下を参照してください。

私たちが見つけたもう1つの非効率性は、新しいコンポーネントがStyledComponentより上から派生した場合、ベースStyledComponentからコピーされたすべてのcss小道具で新しいクラスを作成することです。 以下を検討してください。

const DerivedComponent = styled(StyledComponent)`
  font-family: monospace;
`

StyledComponentから生成された上記のcssクラスにfont-family: monospaceのみを追加する別のcssクラスを作成します。 つまり、以下に示すように、すべての小道具がStyledComponentからコピーされたcssが作成されます。

ここで、上記のStyledComponentとDerivedComponentを一緒に使用すると、（最初は）重複したcssプロパティを持つ2つのcssクラスがあります（フォントファミリーでのみ異なります）。 以下に見られるように;

ご想像のとおり、互いに重複したcss小道具を持つ多くのcssクラスは、非常に急速に成長する可能性があります。

Emotionでは、コンポーネントスタイルが一緒に構成されているため、多くの重複したcss小道具を持つcssクラスになってしまうことがわかりました。

各cssクラスのcss小道具のこの複製がアプリに顕著な影響を与えるかどうかはわかりませんが、感情を使用することを選択する際にこれが考慮されているかどうか疑問に思います。

実行時にCSSStyleを作成して適用する際のEmotionのパフォーマンスに疑問はありません。 感情は、パフォーマンステストで明らかなように、CSSスタイルを適用する上で最も速いものの1つです。
結果として生じるCSSstyleが肥大化するのではないかと心配しています。 また、EmotionはSSR（ed）できるため、スタイルがHTMLにインライン化されるため、（cssスタイルタグを使用して）HTMLファイルが不必要に肥大化する可能性があります。 その結果、ブラウザで不要なcss小道具を使用して解析するタグが大幅に増えます。

スタイル付きコンポーネントが並行モードを完全にサポートしている場合、ほとんどの開発者がスタイル付きコンポーネント（JSSを除く）でMUIをオーバーライドしていることを考えると、より賢明な選択でしょうか？ 2つのcss-in-jsソリューションを含める必要がある場合、感情がバンドルサイズで小さくなるという点は重要ではありません。 そして、MUIの最も実用的なアプリケーションには、そのスタイルのオーバーライドが含まれていると思います。

@petermikitsh感情について結論を下した理由は、実際には結論の4つのポイントです

• スタイル付きコンポーネントと感情の間のわずかな移行コスト
  すでにスタイル付きコンポーネントを使用している開発者は、ほとんど労力をかけずに感情を使用できるはずです。
• ラッパーコンポーネント以外のオーバーライドを追加するには、さまざまな方法があります
  感情からのcx + cssのサポートは、ラッパーコンポーネントを作成したくない場合に、スタイルオーバーライドを追加する代わりに開発者がそれを使用するのに役立ちます。
• 並行モードは確かにサポートされています👍
• 特異性の処理方法

最初の点を念頭に置いて、開発者がバンドルに2つのcss-in-jsソリューションを含めたくない場合、感情に移行するための移行コストは非常に小さく、 styled以外の異なるAPIをサポートします。

@ ko-tossこれを書いてくれてありがとうこれらはすべて良い点です。 感情がすべてのスタイルで1つのclassNameを生成するという事実は、オーバーライドを解決するためのより良いエンジンになります。 複数のclassNameを生成する際に発生する可能性のある問題は、最後に書き込まれたクラスが勝つことです。これは、将来問題になる可能性があります。

別のプロジェクトでは、アトミックcssを使用していました。ここでは、すべてのcssルールが1回だけ書き込まれるため、メモリ消費がはるかに優れていますが、各classNameは1つのアトミックルールであり、どちらが勝つかという理由で、予測可能なオーバーライドを実行するのはかなり困難です。以前にすべてのスタイルを処理して正しくマージすることに決めていない場合は、それらが書き込まれる順序によって異なります。これは、最終的にパフォーマンスに影響を与える可能性があります。

一方、css-in-jsソリューションを使用すると、人々はスタイルの無限の組み合わせをランダムに作成するだけでなく、小道具の値に基づいてかなり構造化されていると思います。

ただし、これらは良い点であり、共有していただきありがとうございます👍

• そうしないと？

[stylex]のアイデアの互換性についてはどうですか（[style9]など）

• そうしないと？

style9またはstylexアイデアと互換性のあるその他のCSSエンジン

これにはビルド時間の設定が必要なようで、多くの人、特に初心者は使用できません。

（これはむしろ参考までに、感情は良い選択です）

https://github.com/cristianbote/goober（1kB 、感情より少し悪いパフォーマンス）

まだ経験はありませんが、いつかやってみたいです。

@cztomsik https://github.com/kuldeepkeshwar/filbert-jsに似てい

インタラクションまでの時間についてグーグル灯台で行われたいくつかのテストは次のとおりです。

https://jantimon.github.io/css-framework-performance/

参考までに、スタイル付きコンポーネントv5、感情v10、感情v11の詳細なベンチマークを、babelプラグインあり/なし、バニラAPI、css props API、スタイル付きAPIを使用して行いました。 これが議論に役立つことを願っています！

https://github.com/simnalamburt/css-in-js-benchmark

アトミックcssとtypescriptのサポートに大きく依存するcss-in-jsライブラリの新しい波を検討しましたか？

• https://github.com/modulz/stitches
• https://github.com/kripod/otion

アトミックcssとtypescriptのサポートに大きく依存するcss-in-jsライブラリの新しい波を検討しましたか？

• https://github.com/modulz/stitches

• https://github.com/kripod/otion

ベンチマークにはありませんが、現在、感情よりも2〜4倍遅いです。 otionには確かにかなり大きな可能性があり、最適化の余地があると思いますが、otionはまだ実際に生産の準備ができていません。

しかし、私はまだステッチをテストしていません。 😃

実際のゼロランタイムライブラリはどうですか？ 誰もリナリアについて言及しているのを見たことがありません。

ある時点でリナリアに出くわしましたが、とても気に入っています。 私の唯一の心配は、ダイナミクスの小道具のスタイルがcss変数のみに依存し、 https：//github.com/callstack/linaria/issues/445に基づくIE11のサポートがないことです。 styled-componentsと比較してもemotionのコミュニティは、現時点でははるかに小規模です。

@TheHolyWaffle
リナリアは素晴らしいです。
適切に設定すれば、css-in-js（開発経験の観点から）と純粋なcss（純粋なcssのパフォーマンスに勝るものはありません）の両方の長所だと思います。 それはcssルールを最適化（重複）して再利用します。
しかし、リナリアは、初心者にとって難しいビルドとバンドルのステップを必要とします。

私は、例えば同様のAPIの面で他のCSS-で-jsのライブラリ用のポートを見てみたいハシバミ-JS / goober

@kuldeepkeshwarスタイル付きAPIのアダプターを調べたら、お知らせします:)

https://compiledcssinjs.com/はこれらすべてにどのように適合しますか？ それは信じられないほど興味深いアプローチのようです。 CompiledはプロジェクトのRFCも実行します。これは、オープンソースとコラボレーションに最適であることが証明されています。 _ウインクウインク_

Webのスタイリングの将来は非常に明るいと思います。そして、Material-UIがあらゆるアプリのスタイリングの頼れるソリューションの不可欠な部分になることを願っています。

コンパイルが

この種の変換により、ツールを構成/セットアップする必要なしに、コンポーネントをすべての消費者に提供できます。 インポートして移動するだけです。 これは強力であり、さらに重要なことに、JSライブラリの現在のCSSが機能するのと同じです。

_CSSは実行時に生成できません。_

この単一の制約は、私たちに多くの扉を開きます。 ビルド時間の最適化。 ランタイム保証。 パフォーマンスのボトルネックはなくなりました。

別の言い方をすれば、人気は良いプロジェクトにとってあまり意味がないことを指摘したいと思います。 私はMUIとこれまでに取り組んできた作業が大好きです。 プレミアム商品になっているのも素晴らしいと思います。
しかし、人気のために「人気のある」_name_を選択することは合理的な議論ではありません。
私は人気が何度も参照されているのを見てきましたが、x人がxテクノロジーを使用しているかどうかを考えても非常に嫌いです-MUIは（私の本では）人気ではなく、パフォーマンスやDXなどに焦点を当てています。

MUIは常に60kの星を持っているわけではなく、人気のある技術を選んだからではなく、最高の技術（またはそれに近い）を選んだからです。

人気投票に基づいて選択することが、より広く親しみやすいプロジェクトであることに関連している場合、それはビジネス上の懸念であり、パフォーマンスの向上の可能性ではありません。 プロジェクトは、ユーザーの有無にかかわらず生きています。 それは悪い選択で死にます。 これについてはたくさんのことわざがあり、「あまり人気がないので、悪い選択です」と読むと、大きな鐘が鳴り響くと思います。

人々は、人気のあるテクノロジーを使用しているからではなく、優れているという理由で適切な製品を使用しています。 MUIはかつてはニッチでしたが、CSS-in-JSがあり、人気投票に勝てなかったにもかかわらず、有名になりました。 それはいくつかの驚くべき特性を持っており、現在のコミュニティではなく実際のDXとパフォーマンスに基づいた正しい選択をしました。

その補足事項に注意してください、私は人気投票の側にいます。 どちらかといえば、私も自分自身を妨害しています。 あまり人気のない製品を選ぶことから得られる個人的な利益はありません。革命や変化について話すとき、人気を「まったく」考慮すべきではないと私は考えています。 オプションの現在の人気に基づいて人々が考えているものではなく、実際に何であるかに基づいてこれらのオプションのいくつかを再考してください。

実際に締めくくるために、私はMUIに入るすべての考えと時間に感謝します。 私は過去数年間、すべての標準などに従っていくつかの驚くべき（悲しいことにプライベートな）ソリューションを作成しました。これは、単独で作成するには数か月または数年かかりました。 感謝の気持ちを紙の上で輝かせるのに十分なほど説明することはできません🙇‍♂️🙏🙇‍♂️

コンパイルされたものがオプションであるかどうか、そしてそれがアダプタなどでどのように機能するかについて、私は興味があります。 コンパイルされたアプローチだと思います。

Compiledは、コードを静的に分析し、それをCompiled Componentsに変換することにより、ビルド時にJSでCSSをコンパイルします。 コンポーネントを使用するために必要なものはすべて、JavaScriptバンドルに含まれています。

コンパイル全体の「実行時のcss」制約を考えると、これは考える必要のあるパスです。

私はこれを感情のメンテナーとして言っています-コンパイルされたのは素晴らしいです。 というか、将来的には、これは非常にエキサイティングなことですが、まだ実験のかなり早い段階です。 現時点では、MUIがそれに対応できるかどうかは非常に疑わしいです。

私が間違っているがコンパイルされている場合は、私を訂正してください。これは、カスタムスタイルを使用しなくても、MUIの構成ファイルを用意する必要があることを意味します。

MUIを使用するためだけに構成を作成することを余儀なくされるのは嫌です。 ちなみに、Create React Appのような意見のあるブートストラッパーで使用するのは難しいことではないでしょうか？

@Andarist私は完全に同意します。 コラボレーションを開始するか、少なくともライブラリの開発への参加を検討することをお勧めします。 私はそれが将来どこにつながる可能性があるかについて興味があります！ ：eyes：あなたが言っているように、コンパイルされたようなものは将来素晴らしいものになると思います。 もっと素晴らしい心が集まって何か注目に値するものを作るのは素晴らしいことです。

@shilangyu何かが足りないかもしれないので、あなたが何を意味しているのかコンパイルされたの

ゼロ構成の現実に移行する

私たちが愛するAPIはすべてここにあります-CSSプロップとクラス名コンポーネントも！ 私たちの消費者は、コンポーネントの消費方法を変更する必要さえなく、バンドラーを構成する必要のないゼロ構成ストーリーを継続し、サーバー側のレンダリングのために特定のものをセットアップする必要もありません。 それはうまくいきます。

始まったばかり

今日は設定がゼロであるため、明日がどのようになるかを忘れることはありません。 オプションのCSS抽出、CSSのアトミック形式への変換、さらにはコードベース全体の分析にCSSデータを使用できる可能性があるため、私たちはエキサイティングな明日を考えています。

@MathiasKandelborg
https://compiledcssinjs.com/をざっと
ビルド時にcssクラスを作成しますが、実行時に<CC>...</CC>タグを使用してそのスタイル（ビルド時に生成されたcssクラスでスタイルタグを作成）を適用します。
純粋なcssを使用するのと同じくらい速い場合、それは本当に未来です（css変数を使用するため）。 共有してくれてありがとう
感情に比べてどれだけ速いのだろうか。

実際のゼロランタイムライブラリはどうですか？ 誰もリナリアについて言及しているのを見たことがありません。

要件に含めなかったのは、Material-UIコンシューマーの観点から、ソリューションはゼロ構成である必要があるということです。 ランタイムゼロのソリューションを理解していれば、コンパイル時にCSSを生成します。 バンドラーを適切に含めるように設定する必要はありませんか？

したがって、ゼロランタイムはおそらく最速のソリューションですが、特別な注意も必要です。 ゼロランタイムで実行するように構成できるゼロ構成ソリューションがあると理想的だと思います。

したがって、ゼロランタイムはおそらく最速のソリューションですが、特別な注意も必要です。 ゼロランタイムで実行するように構成できるゼロ構成ソリューションがあると理想的だと思います。

カントはコンパイルの現在の状態について本当に言いますが、私はそれについてメンテナと何度か話していました、そしてこれは大まかに計画です-アイデアはEmotion＆Styled Components APIのサポートを維持することです、それでそれらを書いたコードを最適化することはただの問題であるべきですインポートを変更し、変換プラグインまたはWebpackローダーを含めます。 確かに、記述できる可能性のあるすべてのコードを処理できるわけではありませんが（JSはワイルドです）、賢明に記述されたコードを処理できるはずです。 何かをコンパイルできない場合は。 それは単にスローします-静的分析を支援するためにそれを使用するか、コードの特定の部分を書き直すことを強制します。

つまり、要約すると、0config Emotion（またはStyled Components）を使用する場合、将来的にはオプションの最適化としてCompiledを適応させることができるはずです（プロジェクトが約束したことを実現できる場合）

@ ko-tossビルド時にスタイル付きコンポーネントにコンパイルされると思います。 実行時に、コンポーネントのスタイルは適切な場所に移動されます。

彼らがウェブページで言うように：

コンポーネントを使用するために必要なものはすべて、JavaScriptバンドルに含まれています。

私たちはあなたの最初のコードをその栄光のすべてで受け取ります：

import { styled } from '@compiled/css-in-js';

export const ColoredText = styled.span`
  color: #ff5630;
`;

そして、それをコンパイル済みコンポーネントに変換します。

...
...

次に、実行時にスタイルをドキュメントの先頭に移動します。

この種の変換により、ツールを構成/セットアップする必要なしに、コンポーネントをあらゆる消費者に提供できます。 インポートして移動するだけです。 これは強力であり、さらに重要なことに、JSライブラリの現在のCSSが機能するのとまったく同じです。

CSSは実行時に生成できません。

ゼロランタイムで実行するように構成できるゼロ構成ソリューションがあると理想的だと思います。

頭に釘を打ったと思います。 いきなり夢を

探求すべきいくつかのアイデアがあり、おそらくいくつかのコラボレーションが必要です。 コードと概念のいくつかは私にとって少し異質なので、私は多くの詳細を説明する立場にありません。 これが私が興奮していることのいくつかです：

• 静的分析-これは大きな問題です。 スタイリングソリューションの使用方法のデータを取得し、Xルール、規則、または仕様に基づいて推奨事項を取得し、最適化できる場所を示すことを想像してみてください。
• ゼロ構成-怠惰を優先してより多くの自由を優先しますが（xバンドラー用のプラグインをインストールする）
• CSS-in-JSSから純粋なCSSへ。基本的にはコンパイル時にスタイルを抽出して静的に含めるため、ランタイムは必要ありません。

IE11のサポートに関して、統計をどのように見ていますか？ それは完全に実行可能なことだと確信しています。 Edgeは現在クロムに基づいており、ほとんどの企業は、各OS IE11がインストールされたときにMSがIEのサポートを最終的に

IE11をサポートしないオプションがあると便利です。 これは、もはや業界標準ではなく、廃止されます。 それは時間の問題であり、MUIのような驚くべきものからの_default_サポートはおそらくシフトを抑制します。

IE11をサポートしないオプションがあると便利です。

詳細については、 https：//github.com/mui-org/material-ui/issues/14420を参照して

IEのサポートを完全に廃止する予定はありません。 デフォルトバージョンはv5のIE11をターゲットにしない可能性がありますが、IE 11ではまったく機能しないソリューションを選択することはできません。むしろ、ビルド時に交換して同じものを生成できるソリューションである必要があります。出力。

これは私を幸せにします。

既存のjsをスタイル/感情に変換するためのコードmodはありますか？

みなさん、こんにちは。 私はこの議論に参加する機会を利用しています。

現在のバージョンでは、MaterialUIはmakeStylesを内部的に使用する動的スタイル（スタイルは小道具に依存する関数）なしでwithStyles HOCを多用します。 makeStyles （動的プロップなし）のパフォーマンスは非常に優れており、不要なラッパーを作成するwithStyles代わりに、マテリアルUIを直接使用すると、さらに高速になる可能性があります。

このベンチマークから分岐したベンチマークを

100枚のカードの場合：

• makeStyles ： https ： makeStyles
• emotion ： https ： emotion
• styled-components ： https ： styled-components

500枚のカードの場合：

• makeStyles ： https ： makeStyles
• emotion ： https ： emotion
• styled-components ： https ： styled-components

2500カードの場合：

• makeStyles ： https ： makeStyles
• emotion ： https ： emotion
• styled-components ： https ： styled-components

全体として、 emotionとstyled-componentsパフォーマンスは非常に似ています。 ただし、 makeStylesは、マウント時に全体で2〜4倍速くなり、更新のために6-8xを再レンダリングするように見えます。

特に、電話などの低電力デバイスでレンダリングしている場合、その違いは十分に重要です。そして、そこには安っぽい電話がたくさんあります。

これはすべて、マテリアルの移行とデフォルトでのemotion使用について心配していることを意味します。これにより、マテリアルUIとそれを使用するサイトのレンダリングパフォーマンスが3〜5倍 （これは実際には当てはまりません。コンポーネントによって異なります。複雑になるほど、違いは少なくなります）。

いくつかの質問と思考の糧：

• DXは本当にUXのトレードオフの価値がありますか？ 多くの人がmakeStyles好むので、DXでさえ議論の余地があります
• makeStylesの問題は、決定論的なキャッシュIDを実装することで修正できるように見える動的スタイルに関係しています。 現在、小道具と出力スタイルが同じであっても、すべてのコンポーネントインスタンスは動的小道具の独自のIDを取得するため、実行時のオーバーヘッド、ヘッド内の多くのスタイルタグ、およびSSRパフォーマンスの低下が発生します。 JSライブラリの他の多くのCSSが行っているように、動的スタイルにハッシュ戦略を使用することで修正できるようです。 関連： https ：
• emotionとstyled-componentsに近づくため、またはmakeStylesよりも優れているために、改善の余地はありますか？
• Material UIは、開発者がパフォーマンスを向上させるために選択できるように、公式のJSSエンジンアダプターをサポートしますか？

わずかなパフォーマンスの低下で生きることができます。

300％のパフォーマンス低下ではなく、コストもかかりません。 😅

@satazorこれを探索してくれてありがとう。 この作業を開始する前に、重いパフォーマンステストを行いました。詳細については、PR https://github.com/mui-org/material-ui/pull/22173を参照してください（ListItemコンポーネントで行いました）。パフォーマンスの違いは次のとおりです。本番モードでx1000インスタンスをレンダリングする場合はほとんど

https://deploy-preview-22173--material-ui.netlify.app/performance/list-raw/

https://deploy-preview-22173--material-ui.netlify.app/performance/list-mui/

https://deploy-preview-22173--material-ui.netlify.app/performance/list-styled/

https://deploy-preview-22173--material-ui.netlify.app/performance/list-styled-wrapper/

• https://github.com/mui-org/material-ui/pull/22173#issuecomment-673486269からコピー

これに基づいて、この違いを無視することにしました。これは、得られるメリット（箱から出してすぐに使える動的な小道具、開発者の大部分がすでに使用しているスタイル付きAPIなど）のためです。概要全体は、 PRの説明:)）

ベンチマークで何が起こっているのかわかりませんが、3〜5倍は私には多すぎるようです。もしそうなら、なぜ誰かがemotion / styled-compoenents使用するのだろうかと思います。何かが足りない場合に備えて、2つのベンチマークの違いがどこにあるかを確認します。 また、私の意見では、実際のMUIコンポーネントでベンチマークを実行する方がはるかに優れているため、より現実的な数値が得られるので、こちら側でさらに調査したい場合はお知らせください。 私がリンクしたPRは良い出発点です。

返信@mnajdovaをありがとう。 Muiコンポーネントでのテストの方が現実的であることは間違いありません。 おそらく起こっているのは、リストコンポーネントのMuiコードが主な速度低下要因であり、それらの違い（〜30ms）は、スタイルに関連する実際のレンダリング時間の違いです。 そのPRのコードを取得してベンチマークに追加し、結果を確認します。

これは最終的に問題になりますか？ おそらくそうではありませんが、アプリによって異なります。 現在のMuiコンポーネントとスタイル付きコンポーネントのパフォーマンスの違いは、レンダリングコード自体が単純になるにつれて大きくなります。 例として、アイコンまたはタイポグラフィコンポーネントの違いは増えるが、カードの違いは減ると予想しています。 したがって、実際にはアプリと、アプリが使用している各タイプのコンポーネントの量によって異なります。

これにより、マテリアルUIとそれを使用するサイトのレンダリングパフォーマンスが3〜5倍低下します。

この要素を持つベンチマークを作成しました。 すべてのコンポーネントがこの減少を示すというわけではありません。 この誤解を招く情報は、このような目に見える問題から非常に簡単に広まるため、結論に飛びつくことは避けてください。

devtools拡張機能を使用すると、感情を伴うマウントで140ミリ秒、makeStylesを使用したマウントで120ミリ秒を見ました。

この要素を持つベンチマークを作成しました。 すべてのコンポーネントがこの減少を示すというわけではありません。 この誤解を招く情報は、このような目に見える問題から非常に簡単に広まるため、結論に飛びつくことは避けてください。

あなたは正しいです、私の前のコメントを見てください。

この要素を持つベンチマークを作成しました。 すべてのコンポーネントがこの減少を示すというわけではありません。 この誤解を招く情報は、このような目に見える問題から非常に簡単に広まるため、結論に飛びつくことは避けてください。

devtools拡張機能を使用すると、感情を伴うマウントで140ミリ秒、makeStylesを使用したマウントで120ミリ秒を見ました。

私が使用するために、ベンチマークを更新しましたactualDurationの代わりにbaseDuration私たちは今、デベロッパーツールプロファイラに示されているものでより多くのインラインの値を参照する必要がありますので、。 baseDurationはメモ化せずに時間を測定しますが、 actualDurationはその逆です。 この変更は再レンダリングのパフォーマンスにのみ影響することに注意してください。現在、再レンダリングの場合、 makeStyles 6〜8倍速くなっています。つまり、キャッシュ/メモ化が改善されていますか？ しかし、私はあなたが見ている値を取得していません。 更新されたリンクで試すことができますか？

@satazorあなたのテストケースは同等ではないと思います。 私たちは良いはずです。

あなたがそれを理解しようとすることができるいくつかの変更は、パフォーマンスの違いを減らすでしょう：

• 反応コンポーネントのマウントには、特に多くのコンポーネントをレンダリングする場合にコストがかかります。 makeStylesはdivを直接使用し、emotion / scは新しいコンポーネントを作成します。 私たちのテーブルベンチマークでは、各追加コンポーネントがベースラインレンダリング時間を追加することを経験しました。したがって、コンポーネントの3つのレベル=> x3の場合（または、 <MenuItem>が<li>よりもほぼx10遅い理由）。
• makeStylesを使用したデモでは、単一のスタイルシートが作成されますが、emotion / scでは作成されません。 CSSセレクターを備えた単一のスタイルシートを使用して、各カードコンテナー内のアイテムをターゲットにしてみてください。 または、逆に、メインのmakeStylesスタイルシートをアイテムごとに1つずつ複数に分割します。

確かに、@ oliviertassinari。 ここで実装したTypographyなどの単純なコンポーネントでも、emotion / styled-componentsの今後のパフォーマンスは最大1.5倍から2倍になるようです： https ：

https://csb-lr3sr-7lp24bj5l.vercel.app/で本番ビルドとベンチマークを確認して

makeStylesは、マウントで1.5〜2倍、再レンダリングで3〜4倍高速です。 これは潜在的に注意を払うべきものですが、より複雑なコンポーネントの場合、偏差ははるかに小さくなると思います。

ですから、結論として、私はもはやパフォーマンスについて

@mnajdovaこれがリストテストの本番ビルドです： https ： //csb-lr3sr-3zi42510w.vercel.app/？components = 1000 、あなたが言及したPRのコピー。 Codesandboxリンク： https ：//codesandbox.io/s/css-in-js-comparison-forked-6s4nl

makeStylesは、マウントで1.7倍、再レンダリングで2.2倍速いようです。 私はあなたが見ている10％の違いを得ていません。 私は何か間違ったことをしていますか？

@satazor興味深い、まとめてくれてありがとう。 このベンチマークを＃22435と使用して、のパフォーマンスを比較しました。

import Slider from '@material-ui/core/Slider';

vs（感情）。

import SliderStyled from '@material-ui/lab/SliderStyled';

vs（スタイル付きコンポーネント）。

import SliderStyled from '@material-ui/lab/SliderStyled';

現時点では、なぜ遅いのかわかりません。 ボトルネックはスタイルにない可能性があります。 そして、私はそれを開発モードで実行したことを覚えておいてください⚠️！

SliderのWIPエモーションバージョンのパフォーマンスを確認するために、2つの新しいページを追加しました。

• https://deploy-preview-22435--material-ui.netlify.app/performance/slider-emotion/
• https://deploy-preview-22435--material-ui.netlify.app/performance/slider-jss/

本番用にビルドすると、統計はhttps://github.com/mui-org/material-ui/issues/22342#issuecomment -697540546に似ているように見え

• 感情： https ： package.json

• styled-components ： https ： //codesandbox.io/s/preact-material-ui-test-forked-lum1y ？ file = / src / index.tsx @mnajdova scの場合、小包を使用する必要があり、使用できませんでしたCRAのテンプレート。

また、withStylesの代わりにmakeStylesを使用することで、現在のJSSバージョンx1.1を高速化できることがわかっていることに注意してください：＃15023。

製品モードの

makeStylesがどのように実装されているかを見ると、静的スタイルを使用した場合にどのように高速になるかがわかり

1. すべてのマウントで、 attachが呼び出されます。
2. そのコンポーネントタイプの最初のインスタンスである場合、 stylesCreator.createが呼び出され、次にfn指定されたmakeStyles(fn) fnが呼び出されます。
3. 他のすべてのインスタンスでは、参照カウントが0より大きいため、 stylesCreator.createはスキップされます。

再レンダリングの場合：

1. 再レンダリングするたびに、 attachが呼び出されます。
2. その後、参照カウントが0より大きいため、 stylesCreator.createはスキップされ、作業はまったく行われません。

動的スタイルが機能している場合、マウントと再レンダリングのたびに、シートがここで更新さ

それどころか、 styled-componentsとemotionは、すべてのコンポーネントインスタンスでスタイリング関数を実行しているように見えます。その結果、CPUサイクルとメモリのバックプレッシャが増加します。 小道具の組み合わせに基づいてマルチメモ化キャッシュを実行できると思いましたが、これはスタイリング関数が純粋であると想定しているため、そうではない可能性があります。

     const someContext = useContext(FooContext);

    return <div css={ { paddingTop: someContext.padding(1) } }>;

私の仮定が正しければ、静的スタイルの生成でmakeStylesのパフォーマンスレベルに到達するのは非常に困難です。これは、その動作方法とAPIの設計方法により、 styledまたはcss APIはできません。

探求できる可能性のある方向がいくつかあります。

• 最初の問題の説明では、Material-UIの動的サポートを使用してパフォーマンスのベンチマークを行っただけです。 静的ケース（v4が使用するもの）のエントリを追加できます。 また、react-jssの静的および動的なケースも考えられます。 これは、利用可能なスタイルエンジンオプションの範囲を理解するのに役立つはずです。
• ボトルネックがどこにあるかを調査できます。 styled-componentsの場合と同様に、jss用のアダプターがあると想像して、パフォーマンスが向上するかどうかを確認できます。 JSSの動的バージョンではさらに悪化するはずですが、静的バージョンと比較することはできます。 多分それはスタイルのない抽象化から来ています。
• ダイナミックなスタイルとスタイルのないもののロックを解除するために費やす価値のある価格の減速を考えることができます。 長いリストをレンダリングする場合は、仮想化を使用するか、ネストされたCSSセレクターに依存します。
  感情とスタイル付きコンポーネントは、柔軟性を提供し、業界によって十分に高速であることが証明されており、Reactも同様です。

どういうわけかemotionがhttps://github.com/emotion-js/emotion/issues/1321とhttps://github.com/emotion-で要求されたようにuseCssフックを公開した場合js / emotion / issues / 1853 、 makeStyles APIを保持できるため、「静的CSS」のメリットを維持できます。 ただし、パフォーマンスを向上させるために、どこでも静的CSSを使用し続けます。これはそれほど「クリーン」ではありませんが、v4ですでに行っていることです。

実際、 ClassNames APIを使用すると、静的CSSパフォーマンスの利点と感情が持つ動的CSSの優れたパフォーマンスを維持する、 withStyles移植を今すぐ行うことができると思います。 const css = useCss()存在する場合は、 useStyles APIポートも簡単に作成できます。

内部で感情を使用するwithStyles + makeStyles APIを維持する主な利点は次のとおりです。

• マテリアルが実行する必要のある移行は実際にはありません。これら2つの機能の移植を行う必要があります。
• Material UIの外部ですでにwithStylesとmakeStylesユーザーは、移行する必要はまったくありません。 動的CSSのパフォーマンスが向上するというメリットを無料で享受できます。
• classes + CSSAPIを維持するために追加のロジックは必要ありません。 styledを使用すると、グローバルclassNameを手動で、またはutilを使用して作成する必要があります。
• この戦略では、 useCssは、 styledではなく、JSソリューションのCSS用のアダプター関数です。
• JSソリューションで他のCSSをサポートするには、useCssフックなどを提供する必要があります。 理想的には、 styledように、webpack / babelエイリアシングを実行してそれらを切り替えることができます。

https://twitter.com/olivtassinari/status/1309247827839680512で、パフォーマンスの問題についてさらに詳しく調べました

• ネイティブ：7.71ms
• スタイルなしのv5：20.89ms
• v4：29.93ms
• v5：37.37ms
• antd：53.48ms
• チャクラ：64.67ms

https://codesandbox.io/s/slider-comparison-forked-jziv6?file=/src/App.js…

ディスカッションの後半でご迷惑をおかけして申し訳ありませんが、

彼らのリストはあなたの要件を正確に満たしていました：

• Worksサーバーとクライアント
• 完全なCSSサポート、パワーのトレードオフなし
• ランタイムサイズはわずか3kb（gzip圧縮、12kbから）
• 完全な分離：セレクター、アニメーション、キーフレーム
• 組み込みのCSSベンダープレフィックス
• 非常に高速で最小限かつ効率的なトランスパイル（以下を参照）
• 高性能ランタイム-サーバーレンダリングでない場合のCSSインジェクション
• 将来性のあるもの：サーバーでレンダリング可能な「シャドウCSS」と同等
• ソースマップのサポート
• 動的なスタイルとテーマのサポート
• プラグインによるCSS前処理

ほぼシャドウCSS標準APIであることに注意してください。 したがって、 jsx属性を削除することで、将来、通常のブラウザですでに機能しているWebコンポーネントに移行することができます。

はい、私はそれが最も人気のあるものではないかもしれないことを知っています。
しかし、Flashは数年前に非常に人気があったことを指摘したいと思います。
しかし、最終的にはWeb標準に準拠していなかったため、SVGが使用できるようになりました。
記録のために、Flashが業界を支配していたとき、SVG標準は長い間存在していました。
私は歴史的な出来事を良い教訓と見なし、人気が防弾の維持可能で将来の証拠であるという最後の指標であるというパターンを見つけようとします。

@mifrej私は個人的にそれで悪い経験をしました： https ：

https://twitter.com/olivtassinari/status/1309247827839680512で、パフォーマンスの問題についてさらに詳しく調べました

• ネイティブ：7.71ms
• スタイルなしのv5：20.89ms
• v4：29.93ms
• v5：37.37ms
• antd：53.48ms
• チャクラ：64.67ms

https://codesandbox.io/s/slider-comparison-forked-jziv6?file=/src/App.js…

感情/スタイルコンポーネント用のbabelプラグインを試しましたか？ タイミングに違いはありましたか？

JSSからの変更は、既存のMUIコンポーネントで使用可能なclasses小道具にとってどのような意味がありますか？ v5移行では、この小道具を幅広く活用している既存のユーザーをどのように探しますか？

代わりに次の構文を使用することを想定しています。https：//next.material-ui.com/components/slider-styled/#unstyled -sliderクラスは基本的に、コンポーネントの各スロットで使用可能なクラスセレクターに置き換えられます。 カスタマイズの例もご覧ください：

利点として、小道具を使用して、それらに基づいて動的なスタイルを適用することができます。

代わりに次の構文を使用することを想定しています。https：//next.material-ui.com/components/slider-styled/#unstyled -sliderクラスは基本的に、コンポーネントの各スロットで使用可能なクラスセレクターに置き換えられます。 カスタマイズの例もご覧ください：

利点として、小道具を使用して、それらに基づいて動的なスタイルを適用することができます。

私はこのAPIが大好きです！ 非常に歓迎すべき変更であり、スタイルエンジンと非常にうまく機能しているようです。

v5に、私が正しく思い出せば、JSSコンパイラはそれらのクラス名をマングルし、確実にそれらをターゲットにすることができませんでしたか？ しかし今、それらはターゲティング目的で公開されるように思われますか？ 🙌また、CSSの優先順位に問題がありました。 そして、これらの懸念はこの新しいアプローチで解決されますか？ このリファクタリングに取り組んでいただきありがとうございます！

@ConAntonakosまさにこれらのクラスは、コンポーネントのスタイルなしバージョンとスタイル付きバージョンの両方を対象にすることができます。 スタイルが呼び出される順序は、もちろん、特異性が同じである場合、新しいスタイルが勝つことを保証します:)

v5より前では、正しく思い出せば、JSSコンパイラはそれらのクラス名をマングルし、確実にターゲットにすることができませんでしたか？

あなたはすでにv4でそれらをターゲットにすることができます。

クラスは基本的に、コンポーネントの各スロットで使用可能なクラスセレクターに置き換えられます。

それらは「基本的に」置き換えられますか、それとも実際に置き換えられますか？ 重大な変更の数を減らすために、古いAPIの一部を保持することにしたと思いました。

重大な変更の数を減らすために、古いAPIの一部を保持することにしたと思いました。

theme.components.overridesに対して同じAPIを維持することにしました-テーマで定義されたオーバーライドは同じように機能します。

インスタンスのオーバーライドについては、クラスセレクターを使用したstyledアプローチがあります。そのため、 classesプロップはサポートされなくなりました。 開発者は今、より柔軟な方法で同じことを行うことができます。

開発者は今、より柔軟な方法で同じことを行うことができます。

代替案があるので、それはとても小さな問題のように聞こえますが、そのための移行コストは莫大です。 移行計画はどのように見えますか？

開発者は引き続きテーマオーバーライドを使用できます。インスタンスオーバーライドをネストされたThemeProviderに移動するだけであれば、2つの間の構造は同じであるため、定義されたスタイルを変更する必要はまったくありません（完全ではありません）。 、しかし、彼らがインクリメンタルアップグレードを望むなら、それは行く方法です）

一方、クラスの小道具は簡単にサポートできますが、その場合、クラスとスタイルの組み合わせが同じコンポーネントで使用されているかどうかは保証できません。 少なくともコンポーネントのスタイル付きバージョンでは、クラスのサポートをバックポートする必要がありますか？

私はこのスレッドの途中でこれを見逃したかもしれません-私のclasses質問に関連する別の質問です。 どのような「正当性」が保証されるのでしょうか。

たとえば、スライダーの例を編集しました。

const StyledSlider = styled(SliderUnstyled)`
  & .MuiSlider-raill {
    display: block;
    position: absolute;
    width: 100%;
    height: 2px;
    border-radius: 1px;
    background-color: currentColor;
    opacity: 0.38;
  }
)

MuiSlider-railつづりを間違えてしまったことに気付くでしょう。 以前のclassesでは、 classes.railようなものがあり、プロパティのスペルを間違えると、スタイルシートにclasses.raillが存在しないというランタイム警告が表示されました。 テーマも同じ振る舞いをしたと思いますか？

私が考えることができるclasses APIの利点：

1. 子間でリークするグローバルCSSセレクターに対するエッジ：例： .css-e7ylz8 .MuiTreeItem-group 。 コンポーネントが子コンポーネントにスタイルを適用しないという保証はありません（期待した効果ではありません、驚きです！）。 注意するので、コンポーネントはおそらくOKです。
2. https://material-ui.com/guides/interoperability/#portals ：ポータルの処理を簡単にし
3. $styleRule構文は、スタイルルールが定義されていない場合に警告します。
4. 使用するクラス名のカスタマイズを許可します。 現在の解決策は、 componentsProps小道具を使用することです。 クラス名をマージします。

私たちが行う代替の世界があります：

a。 スタイル付きコンポーネントセレクターを使用して、1。および3.を解決できます。
b。 下位互換性のためにclasses APIを公開します。
c。 を取得するために。 およびb。 作業するには、コンポーネントのスタイルが内部でどのように記述されているかをフラット化する必要があります。 1つのスタイル付きルートの代わりにxスタイルのコンポーネント。 しかし、⚠️はパフォーマンスに影響します。

私たちは本当にそれをする必要がありますか？

jQuery UIのclasses小道具の歴史を見てきました。 https://bugs.jqueryui.com/ticket/7053、https://bugs.jqueryui.com/ticket/8928と最初のコミット： https ： //github.com/jquery/jquery-の2つの問題を見つけることができましたui / commit / c192d4086d9bbaf09d5f870857af30c60a427e22。

代わりに次の構文を使用することを想定しています。https：//next.material-ui.com/components/slider-styled/#unstyled -sliderクラスは基本的に、コンポーネントの各スロットで使用可能なクラスセレクターに置き換えられます。 カスタマイズの例もご覧ください：

利点として、小道具を使用して、それらに基づいて動的なスタイルを適用することができます。

うわー、これはこれまでで最高のことです。
スタイルなしまたはヘッドレスコンポーネントは、カスタマイズに最適です（muiについての批評家の1人だと思います）。
これはimoを修正するための小さなことではありませんが、MUIのハードプラスです。

PS：過去にいくつかのコンポーネントをカスタマイズするのに苦労したことを覚えています
PS2： https：//github.com/modulz/stitchesをご覧になりましたか？

あなたは私が誤ってMuiSlider-railのつづりを間違えたことに気付くでしょう。 以前のクラスでは、classes.railのようなものがあり、プロパティのスペルを間違えると、classes.raillがスタイルシートに存在しないというランタイム警告が表示されました。 テーマも同じ振る舞いをしたと思いますか？

@ianschmitzスタイル付きコンポーネントセレクターの使用について提案されたオプション@oliviertassinariに加えて、公開するクラスの定数を公開するという別のオプションがあります。 多分次のようなものです：

import { sliderClasses } from '@material-ui/core/Slider';

const StyledSlider = styled(SliderUnstyled)`
  & .${sliderClasses.rail} {
    display: block;
    position: absolute;
    width: 100%;
    height: 2px;
    border-radius: 1px;
    background-color: currentColor;
    opacity: 0.38;
  }
)

これはclasses.railランタイム警告と同じではありませんが、クラスのスペルミスを防ぐのに役立つはずです。

@mnajdovaeslintプラグインを検討することもできます。

classesプロップのサポートに関して-これを確実に実行できるようにするには、コアコンポーネントの各パーツ（スロット）のコンポーネントを作成する必要があります。 たとえば、 Slider場合、レール、トラック、マーク、マークラベル、サム、および値ラベルのコンポーネントを作成する必要があります。 これにより、特異性を高めるためにクラスを使用する代わりに、これらのコンポーネントで直接スタイルを指定できるようになります。 これらの変更は、このPRで見つけることができます-https：//github.com/mui-org/material-ui/pull/22893

これらの変更により、この新しい更新されたSliderコンポーネントのパフォーマンスをv4、ネイティブスタイル、非スタイル、および他の2つの競合ライブラリ（ https://codesandbox.io/s/）と比較できるコードサンドボックスを作成しました

これらのパフォーマンスを、コンポーネントが1つだけで、その一部にクラスセレクターを使用するパフォーマンスと比較すると、 https： //codesandbox.io/s/slider-comparison-forked-jziv6？file = / src / App.jsスロットごとにコンポーネントを追加すると、パフォーマンスが20％低下することがわかります😢

製品版：

• 1つのコンポーネント-https：//csb-jziv6-99lfgp8e6.vercel.app/
• スロットごとのコンポーネント-https：//csb-2tytc-pz2xlac86.vercel.app/

正直なところ、この下位互換性を追加する方がよいかどうかは、現時点ではわかりません。

これらはclassesサポートするための実際のユースケースですか、それともアップグレードを容易にするためだけですか？
移行パスを緩和するためだけにパフォーマンスが20％低下しても大丈夫ですか？
私たちが見ることができないいくつかの代替案はありますか？それは私たちがパフォーマンスコストを支払うことなくこれらの両方を行うのに役立ちますか？

@ianschmitz @ eps1lon @oliviertassinari他:)これについて何か考えはありますか？

TypeScriptでテーマとスタイルを定義して使用できる限り、20％のパフォーマンスを失うのと比較して、移行に時間を費やしてもかまいません。

私は一般的に興味があり、基本的な設計がわからない場合は許してくれますが、 classesはJSSのAPIでしたか？ APIデザインがJSSからスタイル付きコンポーネントに切り替わる場合、 classesサポートし続けることは理にかなっていますか？

これらはclassesサポートするための実際のユースケースですか、それともアップグレードを容易にするためだけですか？
移行パスを緩和するためだけにパフォーマンスが20％低下しても大丈夫ですか？
私たちが見ることができないいくつかの代替案はありますか？それは私たちがパフォーマンスコストを支払うことなくこれらの両方を行うのに役立ちますか？

提案されたAPIで何かを見逃してしまった場合はお詫びしますが、組織内で最もよく見られるIMOのユースケースは、MUIで使用される基盤となるスタイリングシステムの抽象化です。 はい、 @ ConAntonakosが述べたように、 classesは一種の「JSS用API」だと思いますが、消費者にとっては問題ではありませんでした。 消費者として、私は好みのCSS技術を使用することができました（今日、 classes制限はありますか？）。 さまざまな製品を使用した製品が多数あります。

• バニラCSSファイル
• SCSS
• JSS

それらのチームのニーズと好みに応じて。

クラス名をエクスポートすると、CSS-in-JSのフレーバーを使用している場合に役立ちますが、そうでないものについてはどう思いますか？

RE。 20％のパフォーマンス、許容できるトレードオフではない可能性が高いことに同意します。 結局のところ、皆さんはコミュニティの大多数にとって最善のことをする必要があります。 私の考えを提供するだけです😄

私が決して得られなかった1つの願いは、material-uiがreact-nativeと互換性があることでした。 最近の多くのプロジェクトはクロスプラットフォームであり、統一されたスタイリングソリューションを持つことで、クロスプラットフォームコンポーネントに多くの利点がもたらされます。 最終的に、Web側でmaterial-uiを使用し、ネイティブ側でreact-native-paperを使用して独自にローリングし、material-uiAPIで標準化しました。 この新しいスタイリングソリューションが、react-nativeで（一部/すべての）マテリアルUIコンポーネントを使用できるかどうかを理解したいと思いますか？ コンポーネント内のウィンドウ参照は明らかにブロッカーになりますが、スタイリング自体もネイティブをサポートしますね。

@ mschipperheynreact -nativeはこれまでのところ目標ではありません。 これは、潜在的な使用量の+ 5％ （1か月の成長）と+ 50％の労力（推測）です。 機会費用は非常に高く、収益化の方法について明確な方向性はありません（Ionicのモデル以外）。 また、フラッターは、ネイティブターゲットに反応するオーディエンスの大部分をキャプチャしたように見えることに注意し

v5がアルファリリースになっているので、この問題の解決策はありますか？ 特に、スタイリングソリューションはまだJSSに基づいていますか？ JSSに関連する重大なパフォーマンスの問題が発生しているため、新しいソリューションを熱心に期待しています。

@zzzevこれ自体は問題ではありません。 これはRFC（Request for Comments）スレッドです。

私はあなたが話している実質的なパフォーマンスの問題と、JSSからの移行がそれをどのように改善するかについて興味があります。 私の見方では、パフォーマンスの問題がある場合、それはおそらくスタイルではなく、それらの実装方法です。つまり、より少ない処理能力で別の方法でスタイルを作成しても同じ結果が得られる可能性があります。

少なくとも、JSSからEmotion（このスレッドで示されているように、パフォーマンスが低下する可能性が高い）がどのように改善されるかについては関係ありません。

私の理解では、感情は静的スタイルのパフォーマンスにわずかな影響を与え、動的スタイルのパフォーマンスははるかに優れていますが、それは正しくないのではないでしょうか。 このスレッドには多くの異なる数値があり、パフォーマンスの1つの図に調整するのは困難です（そして明らかにそれは個人の状況に大きく依存します）。

別の方法でスタイルを書くべきだと言うとき、それは動的なスタイルを避けることを意味しますか？ または、考慮すべき他のベストプラクティスはありますか？

@zzzev最初の部分は正しくありません（サポートされていない状態からサポートされている状態に移行することを無限のパフォーマンス向上として数えない限り🙂）。

Emotionを使用すると、静的スタイルのパフォーマンスがやや遅くなりますが、動的スタイルのサポートが可能になります。

よくわかりません; current / v4 makeStylesに動的スタイルはありませんか？ 例：このパターン

よくわかりません; current / v4 makeStylesに動的スタイルはありませんか？ 例：このパターン

ありますが、大きな既知のパフォーマンスの問題があります。 私のチームはATMから遠く離れています

コンポーネントスタイルが嫌いです
jssは優れていますが、デバッグ、パフォーマンスにいくつかの問題があり、 &:afterようにネストされているなど、まだ解決されていないバグもあり

それはreact-nativeとreact-native-webのための私のパッケージビルドアップです
https://www.npmjs.com/package/@material-native-ui/theme -provider

私はこのようなものが欲しいです（それはRNとRNWの上に蓄積されています）

では、Material UI v5で使用する推奨スタイルソリューションについて結論はありますか？ @material-ui/stylesが現在構築されているJSSから離れる意図があるようです。 または、 @material-ui/stylesは、代わりにstyled-componentsなどの他のスタイリングソリューションに基づいてリファクタリングされますか？

では、Material UI v5で使用する推奨スタイルソリューションについて結論はありますか？ @ material-ui / stylesが現在構築されているJSSから離れるつもりのようです。 または、@ material-ui / stylesは、代わりにstyled-componentsなどの他のスタイリングソリューションに基づいてリファクタリングされますか？

@ matthewkwong2 @material-ui/stylesパッケージを新しいスタイルのエンジンに採用せず、jssを引き続きサポートします。 v5では、コードベースの残りの部分に分離され、新しいスタイリングエンジンへの移行を支援するために、v6で削除する予定です。

v5の場合、 sxプロップやstyledユーティリティなど、スタイリングソリューションに関する新しいビートプラクティスがありますが、これに関するドキュメントに引き続き取り組んでいます。

また、テーマのオーバーライドとバリアントは、v5でも引き続きサポートされます。

v5の場合、sx propやstyledユーティリティなど、スタイリングソリューションに関する新しいビートプラクティスがありますが、これに関するドキュメントに引き続き取り組んでいます。
また、テーマのオーバーライドとバリアントは、v5でも引き続きサポートされます。

したがって、私が正しく理解していれば、個々のコンポーネントのスタイル設定には、 makeStyles代わりにsxまたはstyledを使用することをお勧めします。

しかし、テーマ（つまりcreateMuiTheme ）はどうですか？ パーツもJSSに基づいていると思いますよね？ 今テーマを作成する（つまり、グローバルスタイルを定義することを主な目的とする）ための推奨される方法は何でしょうか？

テーマを作成するために同じ構造を維持します。コンポーネントのオーバーライドとバリアントの値は、emotion / styled-componentsの構文に従うことを期待しています。 テーマの作成方法に変更はありません。APIはまったく同じです。同じテーマコンテキストが新しいスタイルのエンジンにも再利用されます。 これは@ matthewkwong2に意味が

@ mschipperheynreact -nativeはこれまでのところ目標ではありません。 これは、潜在的な使用量の+ 5％ （1か月の成長）と+ 50％の労力（推測）です。 機会費用は本当に高いです。 また、フラッターは、ネイティブターゲットに反応するオーディエンスの大部分をキャプチャしたように見えることに注意し

私は私たちをあまりにも大きな接線に乗せたくはありませんが、これらの理論的根拠のいくつかを押し戻したいと思います。

• 過去にRNアプリを構築する際に対処するのが最も困難だったのは、マテリアルデザインでした。 実際、それはモバイルアプリの構築をわざわざ行うかどうかを決定する可能性のある十分に大きな問題でした。 有望な新しいライブラリが1つあれば、少し良くなると聞きました。 しかし、MUIが混在している場合と同じくらい有望であるとは思えません。 私だけかもしれませんが、クロスプラットフォームのMUIが実際にRNの使用量を増やしているのを見ることができました。 私はそれがreact-domの使用のほんの一部であることを知っていますが、Webは巨大であり、react-domは現代のWebフレームワークを支配しています。 反応ネイティブの使用量が比較的少ない場合でも、それを使用する絶対的な人数としてはかなりの数になる可能性があります。 現在のMUIユーザーのポーリングは、おそらくnpm統計よりも優れたメトリックになります。
• 私はループから外れていることを知っていますが、ReactNativeを引き継ぐFlutterを購入することはあまりありません。 そのトラフィックの比較は、実際に比較するのに最適な方法ではありません。 非常に多くの交絡因子の影響を受けます（Flutterは新しいため、すでにRNを知っている人が多く、ドキュメントを参照する必要はありません。Flutterのドキュメントは、トラフィックの増加を再参照するのに役立つ可能性があります。RNのドキュメント読み取りトラフィックの一部も発生する可能性があります。代わりにExpoに）。 このやや欠陥のあるGoogleトレンドの比較は、ほぼより良い尺度であり、かなり均一です。 個人的には、Flutterにはいくつかのハードディールブレーカーがあり、RNは、クライアントが次にモバイルアプリが欲しいと言ったときのためにさらに有望です。
• JSSは、（実際には、おそらく最大の）ネイティブに反応してMUIの仕事を作るの最大の課題の一つでした。 まだいくつかの複雑な要因があることはわかっていますが、私見では、感情への切り替えにより、少なくとも実験的にMUIをRNで機能させることの難しさの2/3が解消された可能性があります。

感情への切り替えにより、RNでMUIを機能させることの難しさの2/3が解消された可能性があります

私たちはあなたのPOCを見るのを楽しみにしています😄

私たちはあなたのPOCを見るのを楽しみにしています😄

機会があれば遊んでみたいです。 しかし、人々は一般的に、メンテナが無関心を示しているもののためにPOCを作成することを気にしません。 現在の雰囲気がおそらく放棄されてしまうということであるとき、何かを構築する意味はありません。 したがって、なぜ私はRNの値またはRNの値を将来の可能性として却下することを避けたいのですか。

2つの質問：

1. HOCなしで新しいスタイリングソリューションを使用できますか？ 私は、MUIが現在持っているReactフックAPIが大好きです...スタイル設定された構文が内部のHOCでもあるかどうかはわかりませんが、HOCから離れる努力（Reactライブラリのほぼすべての場所）に勝るでしょう。
2. classesプロップのほとんどのコンポーネントは引き続きサポートされますか（ユーザーが使用できるスタイリングソリューションに完全な柔軟性を提供します）？

fast-refreshは、 create-react-appv4ではデフォルトで有効になっています。 新しい要件として高速更新サポートを追加する必要がありますか？

ギャツビーでこれを試してみてください。 import { Link } from '@material-ui/core'を実行すると、次のようになります。

Can't resolve '@emotion/core' in 'node_modules/@material-ui/styled-engine'
File: node_modules/@material-ui/styled-engine/index.js

Can't resolve '@emotion/styled' in '/node_modules/@material-ui/styled-engine'
File: node_modules/@material-ui/styled-engine/index.js

import Link from '@material-ui/core/Link'変更すると、問題はなくなりました。

@emotion/styled @emotion/coreをインストールすると、次のようになります。

「/ node_modules / @ emotion / styled / dist」の「@emotion / react」を解決できません

次に、 @emotion/reactをインストールします。

ランタイムエラーが発生します。

Error: The `@emotion/core` package has been renamed to `@emotion/react`. Please import it like this `import { jsx } from '@emotion/react'`.
./node_modules/@emotion/core/dist/emotion-core.cjs.dev.js
node_modules/@emotion/core/dist/emotion-core.cjs.dev.js:3

関係するパッケージバージョン：

    "@emotion/core": "^11.0.0",
    "@emotion/react": "^11.0.0",
    "@emotion/styled": "^11.0.0",
    "@material-ui/core": "^5.0.0-alpha.15",
    "@material-ui/lab": "^5.0.0-alpha.15",

Emotionパッケージのv10バージョンをインストールします

Oh 11は現在「最新」バージョンなので、muiはそれをアップグレードまたは文書化する必要があると思います

Oh 11は現在「最新」バージョンなので、muiはそれをアップグレードまたは文書化する必要があると思います

peerDependenciesバージョン範囲で文書化されています。 間もなくv11にアップデートする予定なので、インストール手順では明示的に言及していません。

これはほんの数日前のアルファと感情11であることを友好的に思い出させてください。 早期導入者として、あなたはいくつかの荒削りな部分を期待するべきです。

みなさん、こんにちは。私はここで新しく、material-ui cssソリューションを検討していて、この問題に遭遇しました。
これに2セントを与えるだけで、Linariahttps ：//github.com/callstack/linariaを提案したいと思い
これはゼロランタイムライブラリであり、CSS抽出とCSS変数がReactの小道具として使用されています。

これがこのRFCに役立つことを願っています😄。