Material-ui: [RFC]スタイル付きコンポーネントに移行する

作成日 2017年02月11日  ·  164コメント  ·  ソース: mui-org/material-ui

スタイル付きコンポーネントに切り替えることはできますか?


時代遅れの比較

JSSに対して多くの利点があります
ここに比較表があり、次のバージョンではSSRスタイルの再レンダリングも回避されます。

機能| スタイル付きコンポーネント| react-jss
------------ | ------------- | -------------
ビルド要件なし| ✅| ✅
小型軽量| ✅| ✅
グローバルCSSをサポート| ✅| ✅
CSS全体をサポート| ✅| ✅
コロケーション| ✅| ✅
分離| ✅| ✅
インラインスタイルを壊さない| ✅|✅
オーバーライドしやすい| ✅| ✅
テーマ| ✅| ✅
サーバー側のレンダリング| ✅| ✅
ラッパーコンポーネントなし| ❌| ✅
ReactNativeサポート| ✅| ❌

凡例:✅=はい、❌=いいえ、😕=ちょっと、メモまたは括弧を参照してください

discussion enhancement

最も参考になるコメント

@oliviertassinari https://github.com/mui-org/material-ui/issues/6115#issuecomment -643398897に記載されているように、進行中のパフォーマンステストによると、人気があるため、マテリアルチームがスタイル付きコンポーネントを選択するだけではないことを願っています。 遅いです。 いつもされています。 個人的には、CSSのJS表記などを学ぶ必要があるのは開発者であるという点です。

それは仕事の一部です。

開発者の生活を楽にすることは、パッケージメンテナーとしての私たちの仕事の一部です(私が話している私自身のプロジェクトの場合)が、それを簡単にすることとパフォーマンスを上げることの間には線があります。

そのため、私はmakeStylesのみを使用し、導入されてから常に使用しています。

私の最後のチームアーキテクトは、スタイルを設定されたコンポーネントに耳を傾けず、先に進んでいませんでした。現在、サイトは低速です。 テストブランチでmakeStylesに切り替えて、モバイルデバイスのTTIを50%(10秒)節約しましたが、そのコメントで述べたように、JS表記は誰にも知られていないため、受け入れられませんでした。

内部的には、マテリアルは必要なものを選択できますが、デフォルトでパフォーマンスを向上させてください。

全てのコメント164件

@kybargその号を開いてくれてありがとう! CSS-in-JSSは動く分野であり、過去に行った選択は、問題や解決策が変化するにつれて、もはや有効ではない可能性があります。

過去にスタイルコンポーネントを使用してみませんか?

JSSを選択する前に、利用可能なさまざまなスタイリングソリューションを比較してきました。

次の理由により、スタイル付きコンポーネントを選択しませんでした。

  • 抽象化のコスト。 css-in-js-perf-testsは優れたリソースであり、スタイル付きコンポーネントは内部で魅力を使用します。

    • JSSの場合は22kbを超えて126kbが解凍されました

    • 最初にペイントするまでの時間が遅くなります。 https://github.com/MicheleBertoli/css-in-jsの同等のデモで最初にペイントするまでの時間を比較すると、JSSのパフォーマンスは40%向上しています。

  • classNameとCSSディープセレクターの能力を公開することで、パフォーマンスの高い実装が可能になります。 たとえば、 <Grid /> :#6010の場合。
  • サーバー側のレンダリングの同時実行は不可能です。 JSSが新しいインスタンスをインスタンス化して各リクエストでスタイルを収集する間、スタイルを収集するためにシングルトンに依存しています。 蒸しは本当に限られています。

実際、 @ nathanmarksがインラインスタイルからの移行に取り組み始めたとき、スタイル付きコンポーネントは(存在する)ものではありませんでした。

比較表

グローバルCSSをサポート

https://github.com/cssinjs/jss-globalを使用すると、次のようなものを書くことができます

const styles = {
  '<strong i="35">@global</strong> body': {
    color: 'green'
  }
}

オーバーライドが簡単

これはどうして簡単ではないのですか? Material-UI側には、事前定義された射出オーダーテーブルがあります。 ユーザーランドでは、優れたアフロディーテオーバーライドAPIを実装する媚薬を使用できます。

ラッパーコンポーネントなし

Material-UI側にはラッパーコンポーネントはありません。 withStylesを使用することもできましたが、パフォーマンス上の理由から使用していません。 その高階コンポーネントをユーザーに公開して、コンテキスト実装を抽象化します。

テーマ

内部ではjss-theme-reactorを使用しています。 JSSは、それを可能にする低レベルのAPIを公開しています。

ReactNativeサポート

それは良い点です。react-with-stylesAPIは非常に興味深いものです。 それは私たちが改善できることです!

未来

今後、最も有望な方法は、スタイルの実装を切り替えることができるAPIを使用することだと思います。 それは私たちに2つの利点をもたらします:

  • マテリアル-UIはスタイリングソリューションとの結合が少ない
  • styled-components / aphrodite / ...を使用しているユーザーは、内部で使用されるJSSオーバーヘッドを節約できます。

react-toolboxはそのパスをたどっています。 私の唯一の懸念は、それが追加するオーバーヘッドにあります。 つまり、それだけの価値はありますか?

@kof@mxstbrをループに追加しています。

@kybarg実際、私はあなたが提案していることを完全に理解することはできません。
あなたの質問が示唆するように、私たちはreact-jssを使用していません

あなたが私たちと言うとき、あなたはユーザーまたはMaterial-UIについて話しているのですか?

私のポイントは:

  • styled-componentsはJSSコアよりもはるかに高レベルのライブラリであり、アプリケーション層で確実に使用できます。
  • 上記の比較表は、JSSコアではなく、react-jssに関するものであり、Maxの主観的な意見です。 それは部分的に真実ではなく、部分的には、表からは見えない特定の視点からの見た目です。
  • より効率的な動的スタイリングのために動的ルールレンダリングに取り組んでいます。jss-theme-reactorは現在すでにその仕事をしています。これは最適化の問題であり、おそらくMUIにはあまり関係ありません。
  • MUIが内部で使用するものは、エンドユーザーにとって完全に心配する必要はありません。 ユーザーが行う必要のあるすべてのことは、MUIが内部で何を使用しているか、または少なくともテーマ化のための多かれ少なかれ通常のcssinjs構文を知らなくても可能である必要があります。
  • MUIが現在サポートしていないユースケースを取得して解決する必要があります。 私はいつでも統合プロセスを支援し、gitterで利用できることを嬉しく思います。
  • とにかくreact-nativeサポートとは何ですか? それは単なるWebプラットフォームのサブセットではありませんか? もしそうならそれはうまくいくはずです、そうでなければJSSがreact-nativeをサポートするために何ができる必要があるか教えてください、ここに問題があります。

その表は確かに非常に主観的であり、私自身の経験に基づいています。 FWIW、 styled-componentsはサードパーティのコンポーネントライブラリで動作します。

import { Button } from 'material-ui'

const MyButton = styled(Button)`
  // Only these styles will be overridden
  background: red;
`

これは、コンポーネントがclassNameプロップを内部でいくつかのDOMノードに接続している限り機能します。

const MaterialUIButton = (props) => {
  /* ... */
  // As long as props.className is attached, the above usage will work
  return <button className={`bla ${props.className}`} />
}

とにかくreact-nativeサポートとは何ですか? それは単なるWebプラットフォームのサブセットではありませんか?

いいえ、それほど簡単ではありません😉JSSにサポートを追加するのは難しいことではありません。スタイルオブジェクトをStyleSheet.create()に渡すだけです。 これには、CSS文字列を機能させるためにstyled-components側からもう少し手間がかかります。


私はしばらくの間@javivelascoと話していて、彼がreact-toolboxで行くところが大好きです。 彼の実装は素晴らしく、すべてのサードパーティコンポーネントライブラリがそれを採用することを望んでいます。 彼がここで彼のアイデアでチャイムできるように彼にpingしてください!


サーバー側のレンダリングの同時実行は不可能です。 JSSが新しいインスタンスをインスタンス化して各リクエストでスタイルを収集する間、スタイルを収集するためにシングルトンに依存しています。 蒸しは本当に限られています。

まったく関係がないので、この問題で、これを可能にするAPIのアイデアについてコメントしてください。 何をするかはまだ決まっていませんので、よろしくお願いします。

こんにちは、私はこれについてgitterで尋ねました。 他の人の意見を聞くために、ここにも投稿します。

私はmaterial-ui_next_がカスタムjssソリューションに多額の投資をしていることを知っています。
スタイル付きコンポーネントよりもjssを使用することの重大な利点を発見した人はいますか?

jssは、デコレータ(injectstyles)やプラグインなどのいくつかのパターンを有効にするので優れていますが、デコレータ、カスタムセットアップ、プラグインが必要ないため、スタイルコンポーネントの単純なアプローチの方がはるかにクリーンだと思います。

styled-compでは、すべてのコンポーネントがすでにスタイル設定されているため、スタイルを渡す必要はありません。 そして、あなたは別のスタイルを生み出すために評価できる小道具を渡します
セットアップなし(createJss)
プラグインなし(プレフィックス)
JSONDSLはありません

誰かがこのスレッドをロックする必要があります。

@rainice jssにはデコレータがありません。HOCはreact-jssの実装の詳細であり、ここでは使用されません。

なぜこれをロックする必要があるのですか? それは正気の議論IMOです

ここでのエンドユーザーベースのコンテンツ(libメンテナーではない)は非常に表面的であり、使用するコードの背後にある1行のコードを読み取っていなかったため、これは理解できます。

スタイリングソリューションの選択については詳細に議論されており、決定の背後にある論理的根拠が文書化されており、次のメジャーリリースに向けた開発作業が進行中であるため、これは有用な問題ではないため、終了します。

人々が閉じたスレッドに投稿し続けないほど成熟していることを願っていますが、必要に応じてロックすることができます。

結合の少ないスタイリングソリューションでそのスレッドを前進させることができればよかったのにと思います。
ただし、今のところ、コンポーネントの移行/全体的な改善を完了することを優先する必要があると思います。

@mxstbrスタイル付きコンポーネントに感謝します

これは、コンポーネントがclassNameプロップを内部でDOMノードに接続している限り機能します

これは、 mui:nextがリリースされたときに、使用ガイドのどこかで強調する価値があるかもしれません。 このコメントは私を救った。

IE10のFlexスタイルはjssでは機能しませんが、チャームのようなスタイル付きコンポーネントでは機能します

@yhaiovyiMaterial -UIはIE10をサポートしていません。

ベンダープレフィックスevtl。 jssでまもなく修正される予定ですが、muiがIE10でテストされていない場合は、すべての問題が修正されるわけではありません。

とにかく私は他の問題を発見していませんそして今のところIE10でcssフレックス

マテリアルUIスタイルをスタイル付きコンポーネントでオーバーライドする方法は3つあるようです(簡単かもしれませんが、すべてが花であるとは限りません)。 これが私の要点です。

数行のコードのように、styled-components APIを取得することもできます: https ://material-ui-next.com/customization/css-in-js/#styled -components-api-15-lines-

styled-jssも使用できます。例: https ://codesandbox.io/s/32mvjyjyxq

一般的なJSSの唯一の欠点は、ここでも述べたように、コードエディターにオートコンプリートがないことですが、利点はあります。スタイル付きコンポーネントのようにcssをjsに解析するのは少し過負荷です。

編集:上記の参照された問題に気づきました、興味深い

厄介なのはMuiのコンテキストであり、$# Typography withStyles HOCはコアreact-jssおよびstyled-jssThemeProvider https://codesandbox.io/s/32mvjyjyxq($#$1を入れてみましたTypographyしかしそれは機能しません、編集:nvm、まだそれをいじっています)

後で(v1以降だと思いますが) src/styles/withStylesとMuiThemeProvider + JSSProviderの二重層を単純化し、react-jssやstyled-jssのようにもう少し単純なものにする価値はないのではないかと思います。

完全にそれのために!

2018年3月13日13:55、「CyrilAuburtin」 [email protected]は次のように書いています。

迷惑なのはMuiのコンテキストであり、withStylesHOCは再生されないようです
コアのreact-jssとstyled-jssのThemeProviderとうまく連携します
https://codesandbox.io/s/32mvjyjyxq

後で(v1以降だと思いますが)単純化する価値はないのではないかと思います
src / styles/withStylesおよびMuiThemeProvider+JSSProviderダブルレイヤー


このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/mui-org/material-ui/issues/6115#issuecomment-372655385
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AADOWAbwLOnRoypx9ANCZnKyalZyD0M9ks5td8HNgaJpZM4L-GwD

styled-componentsのようにcssをjsに解析するのは少し過負荷です

CSSへのオブジェクトの解析が:winkであるのと同じように、文字列の解析はほぼ同じ速度ですが、正直言って問題ではありません。 https://github.com/A-gambit/CSS-IN-JS-Benchmarks/blob/master/RESULT.md

ソリューション| CSSを使用する| インラインスタイルを使用する| マウント時間(ミリ秒)| レンダリング時間(ミリ秒)
:--- | :--- | :--- | :--- | :---
..。
スタイル付きコンポーネント| + | -| 182 | 146.84
styled-components-decouple-cell | + | -| 213.53 | 152.39
..。
react-jss | + | -| 198.97 | 297.74

@mxstbr実行時にjsで記述された完全なcssパーサーには間違いなく代償があります。 そのベンチマークはそのコストを測定していません。

実行時にjsで記述された完全なcssパーサーには、間違いなく代償があります。

もちろんですが、文字列ではなくオブジェクトを処理する完全なCSSパーサーにすぎません。 その上、実際のCSS文字列を操作するCSSパーサーは、オブジェクトを処理するパーサーではそれほどではなく、長い間最適化され、調査されてきました。 :赤面:

パーサーを使用したオブジェクトとしてのブートストラップCSSと、パーサーであるstylisを使用したブートストラップCSSのベンチマークについて知りたいのですが、違いはせいぜい無視できると確信しています。

パーサーを使用したオブジェクトとしてのブートストラップCSSと、パーサーであるstylisを使用したブートストラップCSSのベンチマークについて知りたいのですが、違いはせいぜい無視できると確信しています。

はい、それは適切なベンチマークになります。私は少しテストしました。オブジェクトの操作は、10〜20倍速くなるなど、はるかに高速です。

しかし、繰り返しになりますが、どのjssプラグインを含めるかによって異なりますが、構文上のシュガープラグインがたくさんあります。

また、tbh。 私たち全員がISTFに移行するかどうかは関係ありません。

私は少しテストしましたが、オブジェクトの操作は10〜20倍速くなります。

確かに、10ミリ秒(ブートストラップスタイルシート全体を解析するのにスタイリスがかかる時間です)と、アプリケーションのCSS全体を解析する1ミリ秒は、物事の壮大なスキームでは重要ではありません。 誰かのアプリを作ったり壊したりすることはありません。

とにかく、必要以上の通知でこの問題の人々を悩ませるのをやめましょう。

ところで。 このベンチマークはより正確なようです:http: //necolas.github.io/react-native-web/benchmarks/最初の解析後にキャッシュに依存していないのにわかりません。

@mxstbrこの問題は現在ロックされていますが、少し健全な競争は誰にとっても良いことです。 いつでも戻ってきてください-問題が議論の適切な場所でない場合は、gitterchatで私たちを見つけることができます。

この問題は1年以上前のものです。 皆さん、コメントをやめてください。 ディスカッションを新しいものに移すことができます。 議論が始まってから多くの変化がありました。

ただし、ロックの問題を回避するようにしてください。 より良い意思決定を行うために、可能な限り多くのフィードバックを収集し続ける必要があります。

これを明確に伝えるためのツールとしてのロックの問題は問題ないと思います。これに腹を立てたり、言論の自由を奪われたりすることはありませんでした。 この場合、それは本当に問題ありません。

私はより多くのフィードバックを集めるために再開しています、これが人々がまだ興味を持っているものであるかどうか私は興味があります:

Capture d’écran 2019-03-10 à 10 38 56

開発者調査を実施しており、その結果を使用してロードマップを更新します。
スタイルソリューションには、次の要件があります。

  1. バンドルサイズ。 20 KB gzipで圧縮することなく、単一のコンポーネントを使用できるようにする必要があります。 ランキング別:

    1. 感情はこの方向での最良の候補です: 10kBgzip圧縮されています。 ただし、使用する人はほとんどいません。 ダウンロード統計を見ると、 80%はストーリーブックから来ていますか?

    2. styled-componentsの重量は約16KBgzip圧縮されています。 彼の利点はそれを使用する人々の数から来ています。 たぶんReactユーザーの20%?

    3. 約15KBのgzip圧縮されたreactラッパーの重みを持つJSS。 ダウンロード統計を見ると、多くの使用法はMaterial-UIから来ています。

  2. パフォーマンス。 私たちは、人々が私たちのコンポーネントをカスタマイズできるようにしたいと思っています。 それらは可能な限り高速である必要があります。 私が実行できるベンチマークでは、次のランキングが得られます。

    1. 感情

    2. jss

    3. スタイル付きコンポーネント

  3. カスタマイズAPI 。 バリアントのカスタマイズは簡単で、ネストされた要素のカスタマイズは簡単で、新しいバリアントの追加は簡単である必要があります。 現在、 classes API、 theme.overrides API、およびグローバルな決定論的クラス名を持つ機能があります。
  4. 相互運用性!importantを使用することは解決策ではありません。
  5. RTLサポート

スタイル付きコンポーネント、感情、およびJSSについてのみ説明しましたが、それらは異なる代替手段です:linaria、SASSなど。

Material-UIで使用されるCSS-in-JSライブラリで作業する時間があれば、決定に影響を与える可能性があるため、次の2つの問題を追加する価値があると思います。

@ o-alexandrov JSSはstyled-componentsと同じ戦略に従っていますか? 私はあなたの主張を理解していません。 明確にしていただけますか? 違いは何ですか? それはどのように優れているか、価値がありますか?

@oliviertassinari
前のメッセージでは、 styled-componentsについては何も言いませんが、 styled-componentsまたは他のCSS-in-JSライブラリの使用状況を評価するというアイデアを歓迎します。

  • 開発者の経験(親しみやすさと柔軟性、さらなる貢献、開発者による実際の使用法など)
  • パフォーマンス

上記の2つの問題へのリンクは、JSSでの作業の現在のマイナス面についてのみ説明しています。
次のことをどこで見たか忘れましたが、決定を下せるようにするには、最初にすべてのタイプのベンチマークを追加して、決定をより簡単に評価できるようにする必要があるという良い点を指摘したことを覚えています。

個人的に、私は好きです:

  • コミュニティでの採用を大幅に拡大するためのjssのstyled-components
    コミュニティによる採用は、マテリアルUIが考慮すべき重要な側面であると私は信じています。

@ o-alexandrovわかりました。この場合、最初のコメントをトピック外としてマークします。 v5では、コアコンポーネントをスタイリングソリューションから分離する必要があります。 コンポーネントのネイキッド、JSS、エモーション、リナリア、およびスタイル付きコンポーネント(デフォルトとして)バージョンを提供できることを望みます。 それがビジョンです。 今、実装は挑戦的なものになるでしょう!

バンドルサイズ

styled-components $は@ 5.0.0-beta.812.3kBを改善していることが証明されました

カスタマイズAPI

彼らがhttps://github.com/styled-components/styled-components/pull/2625をパッケージまたは外部パッケージのいずれかで導入した場合、Muiと同等のAPIは、いつか必要になる可能性のある非スタイルコンポーネントAPIが不足しているためだと思います、特にレガシーシステムでは、Mui自体にそのAPIがそれほど頻繁に必要になるとは思いません。

それ以外では、

私の個人的な経験から、 styled-componentsは私たちが必要とする機能を提供しているので、どのような情報を収集したいかわかりません。

相互運用性。

この文脈であなたにとってこれは何ですか? 私の知る限り、 styled-componentsの他のフレームワークと同じようにオーバーライドできます。

RTLサポート

これは、コンポーネントのコーディング方法に基づいているのではありませんか? styled-componentsまたはCSS-in-JSライブラリはこれに対して正確に何を提供する必要がありますか?

私の考え

スピード

以前は他のソリューションに比べて低速でしたが、貢献者からのサポートと驚くべき努力により、JSSよりもさらに高速になっています。

サイズ

v5は、このトピックへの取り組みを表す16.2kB 12.3kBと言ったように、さらにスリムになっています。

親しみやすさ

APIは最も人気があるため、人々はよく知っています。実際、ほとんどの場合、 styled(...) ... APIを使用した場合、実際のパッケージではなくAPIを参照してstyled-componentsと呼ばれます。

リアクトネイティブ

Muiはウェブであるため、それだけの重みがありますが、そのために人々はstyled-componentsを採用し続けるでしょう。

コアチーム

強力なコアチーム、今日81の問題と14のPRが開いているので、これらはパッケージを使用する人々の数にとって良い数字です。

また、 @mxstbrのような人々は実際にspectrumでパッケージを使用しているので、彼はパッケージを実際に使用した経験があります。これは驚くべきことです。つまり、パッケージの使用感を実際に知っているということです。

それを取りました

まあ、これ以上良いことはありませんhttps://www.styled-components.com/docs/tooling

UI作成者向け

今日の時点で、設計システムコンポーネントへのstyled-componentsの採用は大幅に増加しています。 Atlassian、GitHub、Orbit、その他多数。

あなたは一人ではないので、これはムイにとって良いことです。おそらく人々はあなたが遭遇する可能性のある潜在的な状況にすでに対処していて、彼らはそれに対処する方法を考え出しました。

TL; DR

styled-componentsをサポートします。

CSSのオブジェクト構文が簡単になったので、JSSが好きです。時々怠惰になり、それらのスタイルをstyle={{styles.dialogTitle}}インラインスタイルとして渡すだけでも、後で簡単にリファクタリングできます。

また、styled-components https://material-ui.com/styles/basics/#styled -components-apiのような要素ラッパーを使用して、さまざまな方法で使用できます。

私はスタイル付きコンポーネントが本当に好きですが、最近、ツリーシェイクを一貫して機能させることを困難にする多くの問題が発生することがわかりました。 私は、material-uiチームが、このライブラリでツリーシェーキングを完全に機能させるために多くの作業を行ったことを知っています。明らかに、それに関するリグレッションは回避する必要があります。

幸い、ツリーを揺るがす問題のほとんどは、 babel-plugin-styled-componentsを使用し、 pure: trueを設定することで解決されます(https://www.styled-components.com/docs/tooling#dead-code-eliminationを参照)。 )。 しかし、まだいくつかの問題が残っています。 例えば:
https://github.com/styled-components/babel-plugin-styled-components/issues/245

もう1つは、スタイル内で外部ヘルパー関数を使用すると、ツリーの揺れが壊れる可能性があることです(その特定の関数を無視するようにterser / uglifyを構成しない限り)。例:

const Button = styled.button`
  font-size: ${externalHelperFunction()};
`

ツリーシェーキングを正しく機能させるには、これらすべての問題を修正できるはずですが、それは確かにトリッキーであり、現在の状態では、箱から出してすぐに理想的な方法で機能するわけではありません。 私は実際には、スタイル付きコンポーネントに切り替えることは良い考えかもしれないと思いますが、これらの問題が解決できる場合に限ります。

@mbrowneツリーの揺れやスタイル設定されたコンポーネントの問題を再現できませんでした。 この問題には再現可能な例が含まれていないため、

// components.js
import React from "react";
import styled from "styled-components/macro";

const Wrapper = styled.div`
  color: blue;
`;

export function MyComponent() {
  return <Wrapper>styled</Wrapper>;
}

MyComponent.displayName = "FancyName";

export function OtherComponent() {
  return "only";
}

// App.js
import React from 'react';
import { OtherComponent } from "./components";

/* code */

デフォルトcreate-react-appです。 MyComponentは本番バンドルには表示されません。

これはrollupだけが問題を抱えているものですか? 問題を理解するための再現可能な例をいただければ幸いです。

@ eps1lonスタイル設定されたコンポーネントに静的プロパティを設定すると問題が発生すると思いますが、試してみてください。

const Wrapper = styled.div`
  color: blue;
`;

Wrapper.displayName = "FancyName";

export function MyComponent() {
  return <Wrapper>styled</Wrapper>;
}

export function OtherComponent() {
  return "only";
}

@mxstbrええ、どちらの場合もスタイル付きコンポーネントがバンドルされています。 displayNameをMyComponentに設定すると、バンドルにMyComponentが含まれていませんでしたが、 styled-componentsは含まれています。 それは基本的にMyComponentに対して行われたすべてを削除します。そのため、私はもともとそれが適切にツリーシェイクしていると思っていました( FancyNameを検索しただけです)。

ただし、それでもstyled-componentsが含まれています。 styledの呼び出しに副作用があると考えても、私は考えます

import React from "react";
import styled from "styled-components";

export function Wrapper() {
  // nonsense
  return styled.div``;
}

export function MyComponent() {
  return <Wrapper>styled</Wrapper>;
}

export function OtherComponent() {
  return "only";
}

{ OtherComponent }をインポートすると副作用はありませんが、スタイル付きコンポーネントはバンドルに表示されます(これはマクロがない場合でも同様です)。 ですから、これはいくつかのバグであるか、何か大きなものが欠けています。 平

// Wrapper.js
import React from "react";
import styled from "styled-components";

export default function Wrapper() {
  // side-effect free module even if styled has side-effects
  const Component = styled.div``;
  return <Component />;
}

// components.js
// commenting this out removes styled-components from the bundle
export { default as Wrapper } from "./Wrapper";

export function OtherComponent() {
  return "only";
}

// index.js
import React from 'react';
import ReactDOM from 'react-dom';
import { OtherComponent } from "./components";
import * as serviceWorker from './serviceWorker';

ReactDOM.render(<OtherComponent />, document.getElementById('root'));

// If you want your app to work offline and load faster, you can change
// unregister() to register() below. Note this comes with some pitfalls.
// Learn more about service workers: https://bit.ly/CRA-PWA
serviceWorker.unregister();

styled-components (https://github.com/eps1lon/styled-components-shake)が含まれます。

react-scripts、webpack、またはstyled-componentsのバグである可能性があります。 いずれにせよ、これらの問題のデバッグは、再現なしでは信じられないほど困難です。

理にかなっています、それを調査してくれてありがとう。

このユースケースでは、 styled-componentsがバンドルに含まれているかどうか(すべてのコンポーネントがそれを使用する必要があるため)は重要ではないと思いますが、使用しないコンポーネントが含まれているかどうかは重要ではありません。そうですね、いいですね。

@mxstbrこれは重要な懸念事項である可能性があります。スタイルが設定されておらず、汎用的なコンポーネント(Modal、Popper、TextareaAutosize、useMediaQueriesなど)がいくつかあります。

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

SASSで。 + 20kB gzip圧縮ではなく、+ 5kB gzip圧縮の増加(今日の時点)が予想されます。

ただし、 @material-ui/unstyledを前に進めると仮定すると、実際には、このパッケージを使用できるため、違いはない可能性があります。

@ eps1lon申し訳ありませんが、静的プロパティの問題は、すべてのコンポーネントに影響を与えているように見えるため、他の人が再現しやすいと思いました...問題を引き起こすさまざまなものがありますが、少なくともそれが機能するいくつかの単純なケース。

ここで再現可能なデモを作成しました:
https://github.com/mbrowne/CRA-error-template/tree/styled-components-tree-shaking
git clone --single-branch --branch styled-components-tree-shaking [email protected]:mbrowne/CRA-error-template.git

Component1のみが正しくツリーシェイクすることに注意してください。

幸いなことに、これらの問題はすべて解決可能であり、 @mxstbrはここで非常に関与しているようです。 私は、少なくとも静的な小道具の問題に対処するPRにすぐに取り組んでいます(私が書いた別のBabelプラグインを使用してすでに動作しているPOCを持っています)。

ツリーの揺れの問題に対処するために、babel-plugin-styled-componentsにPRを開きました。 ここにいる誰かがそれをテストするのを手伝いたいのなら、 @ mxstbrがそれを歓迎すると思います(そしてもちろん私もそうします):
https://github.com/styled-components/babel-plugin-styled-components/pull/248

みなさん、こんにちは。このチケットは現在どこにありますか? プロジェクトがv5で実際に進んでいる方向であれば、MUIに参加して、いくつかのスタイル付きコンポーネントを作成できれば幸いです。

これを一度にやりたいのでなければ、私は推測します(私たちがそれを望んでいるとは思えません)。 まず、スタイル付きコンポーネントにjssからテーマを読み取らせるか、jssにスタイル付きコンポーネントからテーマを読み取らせる必要があります。 目標は、コンポーネントごとにスタイルを移行できるようにすることです。

これはおそらく別のブランチで発生するはずです。 マスターのすべてを一度に変更する必要はありませんが、おそらく1回の変更でリリースする必要があります(v5)。 そうしないと、これはさらに混乱します。

コメントの削除がリクエストされました。

やあみんな、私も貢献する準備ができています...別のブランチは私たちにとって賢明なことのようです...これをやってみましょう...!

@ caprica-6エネルギーに感謝しますが、新しいブランチは必要ありません。 スタイル付きコンポーネントのバージョンを段階的に提供し(+ jssと感情)(v4では不安定)、同時にスタイルなしのストーリーを前進させることができるはずです。 提出する必要のあるPOCがあります。 スタイル付きコンポーネント(v5ベータ)+動的プロップは、JSSおよび静的スタイルの場合よりも少し遅くなりますが、それでも許容できるはずです。

@oliviertassinari私たちがそれに関与できる場所はありますか? 何かに飛び込む前に、メンテナが私を正しい方向に向けるのをちょっと待っていました

スタイル付きコンポーネントよりも感情を好まないのはなぜですか? 「[感情]は少数の人しか使っていない。ダウンロード統計を見ると、80%はストーリーブックから来ているのか?」という理由のようですが、これは間違いです。 これはスタイル付きコンポーネント(比較)よりも使用されており、ダウンロードの80%がストーリーブックからのものである理由がわかりません。 それは明らかにストーリーブックよりもはるかに速く成長しています。

私は(私が遭遇した複数の問題のために)スタイル付きコンポーネントを使用することにうんざりしていて、代替案を探していたので、この質問をしました、そして私は感情を発見しました。 私はそれをテストし、スタイル付きコンポーネントと比較した場合にのみ利点を見つけました。

より軽く、より速く、より多くの機能を備えています:プロパティ転送、TypeScriptはすぐに使用でき(スタイル付きコンポーネントと比較して完全にサポートされています)、Next.js SSRはすぐに使用できます(_appを上書きする必要はありません)。 jsファイルと_document.jsファイル、最初の処理に1時間かかったもの)

さらに、スタイル付きコンポーネントよりも使用されており、明らかに勢いがあります。

@lcswillems私たちはそれを好む人々の感情もサポートすべきだと思います。 しかし、私はそれがデフォルトであるべきだとは思いません。

  • 「軽い」:正確ではない: https ://bundlephobia.com/result?p = styled-components @ 5.0.0-rc.1(12.2 kB)vs https://bundlephobia.com/result?p=@emotion/スタイル付き+ https: //bundlephobia.com/result?p=@emotion/core+ https://bundlephobia.com/result?p=emotion-theming (共有依存関係を考慮せずに13.1 kB)
  • 「Next.jsSSRをすぐに使用可能」:インライン化することは重要な問題だと思います

あなたの答えと私を訂正してくれてありがとう。

  • 「ライター」:あなたは正しい
  • 「Next.jsSSRをすぐに使用できる」:SSRをすぐに使用できる理由と、それを実行する方法が適切でない理由を理解しました。
  • 「スタイル付きコンポーネントよりも使用されている」:これが信頼できるかどうかはわかりません。 しかし、私の情報源も信頼できないかもしれません。
  • 「より速い」:古いベンチマークしか見なかったので、いいえ、持っていません。

私が直面している主な問題は、プロップの転送/フィルタリングです: https ://github.com/styled-components/styled-components/issues/439。 それは私には非常に頻繁に起こり、毎回手動でフィルタリングを行うのは面倒です。

しかし、あなたの発言では、感情はあまり良い選択肢ではないようです。

「軽い」:正確ではない: https ://bundlephobia.com/result?p = styled-components @ 5.0.0-rc.1(12.2 kB)vs https://bundlephobia.com/result?p=@emotion/スタイル付き+ https://bundlephobia.com/result? p=@emotion/core+ https://bundlephobia.com/result?p=emotion-theming(13.1 kB

Emotionの場合、 css小道具+ @jsxプラグマを優先して、 @emotion/styledパッケージを使用しない可能性があります。 また、 emotion-themingパッケージは必要ない場合があります。 ThemeContextはすでに@emotion/coreに含まれています。 つまり、12.2KB対6.5KBです。

インライン化

好奇心が強い:これらの更新は、MUI以外のコンポーネントの@material-ui/stylesライブラリのユーザーにとってどのような意味がありますか? 私の会社では、これを大規模な内部コンポーネントライブラリのベースとして使用しており、 styled-componentsを超えて意図的に選択しており、非常に満足しています。

@material-ui/stylesパッケージに何らかの非推奨が計画されているかどうかを事前にチェックして、それに応じて計画できるようにしようと思っただけです。

とにかく、あなたが提供し続けているすべての素晴らしいものに感謝します!

@nickjohnson-devreact-jssへの移行は簡単です。 それはあなたの組織でうまくいくでしょうか?

@oliviertassinariそうなる可能性が高いと思います。 コンポーネント自体のパブリックAPIをほぼ同じに保つことができる限り( classesプロップベースのローカルオーバーライド、テーマで可能なグローバルオーバーライド)、実装の詳細を変更することは問題ではないと思います。

MUIがさらに分離された後、 @material-ui/stylesから他のスタイリングオプションに移行するための公式ドキュメントがあると思いますか? 一見したところ、 @material-ui/stylesで活用しているreact-jssに欠けている機能は見当たりませんが、MUIパッケージが行っている特別な機能が欠けているかどうかはわかりません。舞台裏。

@nickjohnson-dev私たちは最善を尽くします。

私が正しく理解すると、次の問題が発生します。
再利用可能なComponentAがあります。 ComponentA ComponentBを作成します。

const ComponentA = ({className}) => (
  <div className={className}>
    <div className='inner' />
  </div>
);

const ComponentB = ({ className, classNameInner }) => (
  <div className={className}>
    <div className='inner'>
      <ComponentA className={classNameInner} />
    </div>
  </div>
)

const StyledComponentB = styled(ComponentB)`
     ???
`;

ComponentAComponentBの両方に同じclassName='inner'の要素があることに注意してください。 ComponentBのみで.inner要素をターゲットにするにはどうすればよいですか?

こんにちは@oliviertassinari 、マテリアルUIの次のバージョンのスタイリングの背後にあるすべての考えを共有していただきありがとうございます。

また、マテリアルUIにも感謝します。 今、その上にデザインシステムを構築しています。

styled-componentsの採用については、決定したようで、すでに始まっている目標に向けて取り組んでいます。

ただし、 @croraf@lcswillemsによる観察結果の一部を共有します

現在のマテリアルUIのスタイルから優れているのは、 classesプロパティです。

classesの入力はパブリックインターフェイスの一部であるため、スタイルのカスタマイズと保守性に大いに役立つのは単純なアイデアです。 たとえば、何かをカスタマイズする必要があり、 & .Component-rootのようなセレクターを使用する場合、 Componentがバージョン間でそのcssクラスを維持することを保証するものは何もありません。 少なくとも<Component classes={{root: ....}} />を使用することで、インターフェイスの変更に関するタイプチェックエラー(TypeScriptを使用している場合)を取得できます。

コンポーネントの作成者として、公開されている(そしてサポートされている)クラスを文書化し、他のクラスを文書化しないままにすることを決定できます。

style-componentsを約2年間使用しました。 確かに人気があり、大きく進化しました。 しかし、MUIドキュメントの例では、 @ croadが言及しているのと同じ問題があります。子孫セレクター& .innerを使用すると、スタイルをサブコンポーネントに伝播できるため、非常に壊れやすくなります(そして、私自身の経験から言えます)。それはコーナーケースではありません...それは私に数回起こりました)。 2つの可能な解決策は次のとおりです。

  • &.innerを使用してから、どこでも${props.className}.innerを使用します。 私はそれを何度もやりました、そして書くのは苦痛です。
  • > .innerを使用しますが、コンポーネントの構造によって異なります。 真ん中にdivを追加すると、壊れます。

JSSは人気がないのは事実です。 私はMUIのおかげでそれについて学びます。 しかし、 styled-componentsで長い間働いた後、MUIスタイルのアプローチがすっきりしていて、扱いやすくなっていることに気付きました(しばらくすると、Styled HOCがどこにでもあると、多くの余分な作業が追加され、それらを嫌いになりましたHOC ...少なくともそれは私の個人的な経験です)。 感情は多かれ少なかれ現在のアプローチと一致します。 そして、あなたのコメントと、特定の場合のJSSパフォーマンスに関するいくつかの問題を読んだ後、私は設計システムにEmotionを使用することを評価しています。

ただし、 styled-componentsについて非常に確信しているので、 classesの小道具を使用してスタイルのカスタマイズを解決する方法の例をもっと見てみたいと思います。 現在のMUIドキュメントで利用可能なものは、私が上で述べた問題を共有しています。

クラスプロップでstyled-componentsを使用する他の方法はありますか? それについてどう思いますか?

JSSは十分に優れており、非常に便利です。 引っ越す強い理由はありますか?

個人的には、styled-componentは一種の後退であり、正直に言うとJSSがこのライブラリを使い始めた主な理由だと思います。

@powerfuljなぜStyled-componentsよりもJSSを好むのですか? 私は2つから選択する必要があり、スタイル付きコンポーネントの方が私には適しているようでした。

@lcswillems
新しいコンポーネントを導入するのではなく、プロパティを操作するだけなので、気に入っています。 スタイリングされた新しい再利用可能なコンポーネントが本当に必要な場合は、JSSソリューションを使用して簡単に作成できます。

また、インラインスタイルからJSSスタイルへの変換が高速です。これは、通常、実装時にインラインスタイルを使用し、大きくなって再利用される場合はJSSに変換するので便利です。

マイナス面は、CSS(ブラウザーのdevtoolsなど)があり、それをJSSに変換する必要がある場合、構文を調整するためにもう少し時間を費やす必要があることです。 スタイル付きコンポーネントを使用すると、これはより高速になります。

この問題に関する私の発見を共有するためだけに。
#16947で要求されているように、いくつかのデモをスタイル付きコンポーネントに移行しようとしました。 問題はデフォルトのテーマにあります。 makeStylesは、defaultThemeを渡すことができるオプションを受け入れます。 defaultThemeを提供する$ makeStylesラッパーがあります。 次に、 useStylesフックは、 ThemeProviderがテーマを提供するかどうかを確認し、提供しない場合はdefaultThemeを挿入します。

スタイル付きコンポーネントにはそのような機能はないようです。 ThemeProviderがない場合、defaultThemeは.attrsメソッドでのみ注入できます。 makeStylesラッパーに似たものを作成する場合があります

import styledWithoutDefault from 'styled-components';
import defaultTheme from './defaultTheme';

const styled = Component => {
  return styledWithoutDefault(Component).attrs({ theme: defaultTheme });
};

export default styled;

ただし、 .attrsメソッドは、 ThemeProviderによって提供されるテーマを上書きするだけです。 そして、私は現在、この問題を解決する方法を知りません。

もう1つの問題は、 makeStylesjss-plugin-default-unitプリセットを使用しており、styled-componentsは使用していないように見えることです。 したがって、スタイル付きコンポーネントは、 spacing() pxを追加しません。
最後の問題に対する可能な解決策は、styled-componentsではなくStyled-JSSを使用することです。

私はここにあなたのアイデア/提案をうれしく思います。

@ fyodore82 .attrsは関数として機能するため(https://www.styled-components.com/docs/api#attrsを参照)、次のようになります。

`` `js
.attrs(({theme = defaultTheme、... props})=>({... props、theme}))
`` ``

@croraf

新しいコンポーネントを導入するのではなく、プロパティを操作するだけなので、気に入っています。

あなたはStyled-componentsの本当に素晴らしいものを見逃していると思います: css小道具。 これにより、新しいコンポーネントを作成しなくても、CSSをコンポーネントに追加できます。

また、インラインスタイルからJSSスタイルへの変換が高速です。これは、通常、実装時にインラインスタイルを使用し、大きくなって再利用される場合はJSSに変換するので便利です。

CSSプロップを使用する場合、CSSプロップを使用するコンポーネントにはstyle属性がなく、スタイル付きコンポーネントに既に変換されているため、 classがあることに注意してください。 CSSが大きくなって再利用される場合は、新しいコンポーネントを作成することもできます。

マイナス面は、CSS(ブラウザーのdevtoolsなど)があり、それをJSSに変換する必要がある場合、構文を調整するためにもう少し時間を費やす必要があることです。 スタイル付きコンポーネントを使用すると、これはより高速になります。

同意します。 これが私がそれを使わなかった主な理由です。 オンラインで書かれたCSSのほとんどは、JSSではなくCSSで書かれています。 したがって、StackOverflowのコードを使用する場合は、最初にそれをJSSに変換する必要がありますが、これは非常に面倒です。

Styled-componentsを使用させたその他の追加の引数:

  • JSSを作成するのはもっと面倒です。引用符を追加する必要があり、構文を強調表示していません(または、引用符が見つかりませんでした)。
  • 初心者にとっては理解しにくいです。 誰もがCSSを知っているので、JSSの場合とは異なり、Styled-componentsを使用してコードを簡単に読み取ることができます(JSS構文は一般に少し奇妙で、特に疑似セレクターやメディアクエリの場合)。
  • コードははるかに読みにくいです。 この点を説明するために、このカードコンポーネントの例をStyled-componentsで書き直して、それらを使用するとどれだけ明確になるかを示します。

JSSバージョン:

import React from 'react';
import { makeStyles, useTheme } from '@material-ui/core/styles';
import Card from '@material-ui/core/Card';
import CardContent from '@material-ui/core/CardContent';
import CardMedia from '@material-ui/core/CardMedia';
import IconButton from '@material-ui/core/IconButton';
import Typography from '@material-ui/core/Typography';
import SkipPreviousIcon from '@material-ui/icons/SkipPrevious';
import PlayArrowIcon from '@material-ui/icons/PlayArrow';
import SkipNextIcon from '@material-ui/icons/SkipNext';

const useStyles = makeStyles(theme => ({
  card: {
    display: 'flex',
  },
  details: {
    display: 'flex',
    flexDirection: 'column',
  },
  content: {
    flex: '1 0 auto',
  },
  cover: {
    width: 151,
  },
  controls: {
    display: 'flex',
    alignItems: 'center',
    paddingLeft: theme.spacing(1),
    paddingBottom: theme.spacing(1),
  },
  playIcon: {
    height: 38,
    width: 38,
  },
}));

export default function MediaControlCard() {
  const classes = useStyles();
  const theme = useTheme();

  return (
    <Card className={classes.card}>
      <div className={classes.details}>
        <CardContent className={classes.content}>
          <Typography component="h5" variant="h5">
            Live From Space
          </Typography>
          <Typography variant="subtitle1" color="textSecondary">
            Mac Miller
          </Typography>
        </CardContent>
        <div className={classes.controls}>
          <IconButton aria-label="previous">
            {theme.direction === 'rtl' ? <SkipNextIcon /> : <SkipPreviousIcon />}
          </IconButton>
          <IconButton aria-label="play/pause">
            <PlayArrowIcon className={classes.playIcon} />
          </IconButton>
          <IconButton aria-label="next">
            {theme.direction === 'rtl' ? <SkipPreviousIcon /> : <SkipNextIcon />}
          </IconButton>
        </div>
      </div>
      <CardMedia
        className={classes.cover}
        image="/static/images/cards/live-from-space.jpg"
        title="Live from space album cover"
      />
    </Card>
  );
}

スタイル付きコンポーネントのバージョン:

import React from 'react';
import styled from 'styled-components';
import { useTheme } from '@material-ui/core';
import MuiCard from '@material-ui/core/Card';
import MuiCardContent from '@material-ui/core/CardContent';
import MuiCardMedia from '@material-ui/core/CardMedia';
import IconButton from '@material-ui/core/IconButton';
import Typography from '@material-ui/core/Typography';
import SkipPreviousIcon from '@material-ui/icons/SkipPrevious';
import MuiPlayArrowIcon from '@material-ui/icons/PlayArrow';
import SkipNextIcon from '@material-ui/icons/SkipNext';

export default function MediaControlCard() {
  const theme = useTheme();

  return (
    <Card>
      <Details>
        <CardContent>
          <Typography component="h5" variant="h5">
            Live From Space
          </Typography>
          <Typography variant="subtitle1" color="textSecondary">
            Mac Miller
          </Typography>
        </CardContent>
        <Controls>
          <IconButton aria-label="previous">
            {theme.direction === 'rtl' ? <SkipNextIcon /> : <SkipPreviousIcon />}
          </IconButton>
          <IconButton aria-label="play/pause">
            <PlayArrowIcon />
          </IconButton>
          <IconButton aria-label="next">
            {theme.direction === 'rtl' ? <SkipPreviousIcon /> : <SkipNextIcon />}
          </IconButton>
        </Controls>
      </Details>
      <CardMedia
        image="/static/images/cards/live-from-space.jpg"
        title="Live from space album cover"
      />
    </Card>
  );
}

const Card = styled(MuiCard)`
  display: flex;
`

const Details = styled.div`
  display: flex;
  flex-direction: column;
`

const CardContent = styled(MuiCardContent)`
  flex: 1 0 auto;
`

const CardMedia = styled(MuiCardMedia)`
  width: 151px;
`

const Controls = styled.div`
  display: flex;
  align-items: center;
  padding-left: ${props => props.theme.spacing(1)}px;
  padding-bottom: ${props => props.theme.spacing(1)}px;
`

const PlayArrowIcon = styled(MuiPlayArrowIcon)`
  height: 38px;
  width: 38px;
`

最後に、JSSを使用する利点は見つかりませんでした。

cssプロパティは非常に優れており、基本的に私が述べた欠点を解決します。 (コピーキャットフォームスタイルコンポーネント:D)

2つの例の比較に関しては、あまり読みやすくなく、コンポーネントの数が2倍になります。

@lcswillems

どちらかの解決策を主張するのではなく、いくつかのポイントを取り上げるだけです。

StackOverflowのコードを使用する場合は、最初にそれをJSSに変換する必要がありますが、これは非常に面倒です。

CSSをCSS-in-JSに変換するためのVSCode拡張機能がありますが、常に完全に機能するとは限りません。 とにかく、私はそれを苦痛とは言いません。

構文の強調表示はありません

私はこの議論をよく理解していません。 これは単なるJSオブジェクトであるため、エディターの構文の強調表示は機能します。

image

(しかし、おそらくあなたはもっと具体的なものを探していますか?)

2つの例の比較に関して、私はそれがそれほど読みやすいとは思いません。 classNameの小道具がないことは間違いなくクリーンですが、メインのJSXコードブロックから、コンポーネントがMUIネイティブコンポーネントを参照しているか、 styled()コンポーネントを相互参照せずにスタイルを変更したかは明らかではありません。 より大きなコンポーネントでは、これらははるかに削除される可能性があります。

styled()の呼び出しは、(私にとっては)JSSオブジェクトよりも読みにくくなっています(私はあなたがそれらに慣れていると思いますが)。

@powerfuljなぜStyled-componentsよりもJSSを好むのですか? 私は2つから選択する必要があり、スタイル付きコンポーネントの方が私には適しているようでした。

私自身はTypescript開発者であり、すべてをTypescriptオブジェクトで構築することを好みます。 特に弦が嫌いです。

違いのためにCSSコードをJSSコードに転送する必要がありますが、構造が従来のCSS(クラス指向)に似ているため、JSSコードを読むことを好みます。スタイル付きコンポーネントコードは長いため、より多くの時間を費やします。あちこちにいることができます。

過去にStyled-componentの経験があるという理由だけで、人々はこの変更を主張したと思います。 「なじみのあるが、明らかなメリットがないライブラリを選んでみませんか?」という感じがします。

私の見解では、JSSは非常に便利であり、次のようなすべてのJavascriptの方法を使用してオブジェクトを整理できます。

{{
... sharedJSS1、
... sharedJSS2、
なんでもいい
}

また、タイプと統合されたシームレスな動的テーマがあり、classNameタイプとcssタイプの両方からすべてのタイプヒントを取得しました。

新しい開発者、特にTypescript開発者にとっては、JSSが大好きです。

参考までに、すべてに対して個別のコンポーネントが常に必要なわけではない場合は、スタイル付きコンポーネントでいくつかのネストを行うことができます。 意味のある名前を持つ個別のコンポーネントを使用することは、スタイル付きコンポーネントの哲学に従ってよりクリーンで読みやすいと見なされるため、一般的には推奨されませんが、ドキュメントでは、「控えめに使用」すれば問題ないと述べています。 そしてもちろん、その哲学を共有していない人のために、彼らはより多くの入れ子を自由に行うことができます。 ネストの意味の例として、次のようにします。

const Wrapper = styled.div`
  display: block;

  .inner {
    flex: 1;
  }
`

...
  <Wrapper>
    <div class="inner">...</div>
  </Wrapper>

詳細については、 https: //www.styled-components.com/docs/faqs#can-i-nest-rulesを参照してください。

コーディングスタイルの好みに関する議論は永遠に続く可能性があります。

styled-componentsをしばらく使用した後、私はJSSアプローチがもっと好きです。理由は次のとおりです。

  • スタイルが長くなると、通常は別のファイルに移動します。
    私もstyled-componentsでそれを行いましたが、 useStyles / makeStylesの方が書き込み、読み取り、保守が簡単であることがわかりました。 例えば。 import useStyles from './MyComp.styles' vs import {XStyled, YStyled,...} from './MyComp.styles' ...これらの...StyledのバリエーションをTSでの入力で維持するのは面倒です。
  • 私は進歩的な方法で物事を行う傾向があります。最初にdivとclassesを使用してドラフトから始め、次にそれらをコンポーネントにリファクタリングします。 styled-componentsを使用する場合、(@ mbrowneの例のように)内部クラスを使用してこれを行いますが、より多くのリファクタリング作業が必要になります。 useStylesアプローチは、そのワークフローでの作業がはるかに快適であることがわかりました。
  • テンプレートリテラルはCSSコードを貼り付けるのに適していますが、テーマ/プロップ変数を使用する必要がある場合はひどいです。 コードの貼り付けの問題はプラグインで簡単に解決できますが、テンプレートリテラル内の変数と関数を使用して編集することはそれほど多くありません。

しかし、これらは私の個人的な好みであり、あなたの好みは異なるかもしれません。

私の最大の未解決の質問は、変更についてclassesの使用法です。

classNameと内部クラスの使用例には問題があります(私の前のコメントを参照)。 styled-componentscss小道具は、これらの問題を解決するためのオプションではありません。 Emotionのcss関数とは異なり、$ cssプロップはコンポーネントにアタッチされていることに依存しています(つまり、 useStyle/makeStyles/classesコードスタイルでは使用できません)。

コンポーネントへのスタイルの添付は、マイナーな設計上の決定ではありません。 私にとって、それはJSSの良い点と悪い点です。 スタイル付きコンポーネントとEmotionは、Babelプラグインに依存し、Reactと対話して、SSRのキャッシュとクラス名の生成を処理します。 JSSの良いところは、Babelプラグインを必要としないことです。 悪い部分は、JSSのSSRがより多くの作業を必要とすることであり、その領域でバグが報告されているのを見てきました。

MUIに戻ると、スタイルコンポーネントを採用するということは、スタイルをカスタマイズする唯一の方法としてclassNameと内部クラスを使用することを意味するという印象を受けています。 スタイリングはフレームワーク間でより一貫性があります。コンポーネントが適切なclassNameを使用している限り、 styledまたはcssプロップを使用できます。

しかし、私にとってclassesプロップを削除することは一歩後退です。 その小道具は、チェックスタイルのカスタマイズを文書化して入力するのに役立ちます。 おそらく、スタイル付きコンポーネントを使用するが、 classesのサポートを維持する(内部クラスのハックを必要としない)などの中間点を見つけることは可能です。 その場合に役立つstyled-componentsAPIには何も見つかりませんでした。 そのため、JSSの技術的な問題を評価することをお勧めします。 人気が主な問題である場合、感情も人気が高まっているため(https://2019.stateofcss.com/technologies/css-in-js/#tools-section-overviewを参照)、 makeStyles書き直します。

@ dfernandez-asappは、このfwiwのごく一部に返信するだけでいくつかの優れた点を指摘しました。@ styled-componentsは、文字列の代わりにjssに似たオブジェクトの使用をサポートしていますhttps://www.styled-components.com/docs/advanced#スタイルオブジェクト

それはかなり残念なスタイルですが、コンポーネントはファーストクラスのタイプスクリプトのサポートを削除し、あなたが説明した他の方法で一歩後退したように見えることに全体的に同意します

参考までに、すべてに対して個別のコンポーネントが常に必要なわけではない場合は、スタイル付きコンポーネントでいくつかのネストを行うことができます。 意味のある名前を持つ個別のコンポーネントを使用することは、スタイル付きコンポーネントの哲学に従ってよりクリーンで読みやすいと見なされるため、一般的には推奨されませんが、ドキュメントでは、「控えめに使用」すれば問題ないと述べています。 そしてもちろん、その哲学を共有していない人のために、彼らはより多くの入れ子を自由に行うことができます。 ネストの意味の例として、次のようにします。

const Wrapper = styled.div`
  display: block;

  .inner {
    flex: 1;
  }
`

...
  <Wrapper>
    <div class="inner">...</div>
  </Wrapper>

詳細については、 https: //www.styled-components.com/docs/faqs#can-i-nest-rulesを参照してください。

これに対するタイプのサポートはありますか? それとも、どこにでも文字列を配置する必要がありますか?

スタイル付きコンポーネントにこれほど多くの誇大宣伝がある理由がわかりません。 正直に言うと一歩後退したような気がします。 TypeScriptを使用したJSSの型付きCSSプロパティは、はるかに便利で保守が簡単です。さらに、JSの一部として構文チェックがあります。最新の/構成済みのエディターは、タイプミスがあったかどうかを通知し、必要に応じてオートコンプリートを支援します。

編集:入力されています。以下のSouth-Pawの返信を参照してください。

@martinjlowmは私にはタイピングがあるように見えますか?

image

参照: https ://styled-components.com/docs/advanced#style -objects

あなたは誇大広告を理解していないと言います...しかし、私はそれが得るすべての憎しみを理解していません。 🤷‍♂

感情とスタイル付きコンポーネントは、CSSスタイルオブジェクトIMOよりも大幅に改善されています

@martinjlowmは私にはタイピングがあるように見えますか?

..。

参照: https ://styled-components.com/docs/advanced#style -objects

あなたは誇大広告を理解していないと言います...しかし、私はそれが得るすべての憎しみを理解していません。 🤷‍♂

感情とスタイル付きコンポーネントは、CSSスタイルオブジェクトIMOよりも大幅に改善されています

そうか! 私はそれがそのようなオブジェクトをサポートしていることに気づいていませんでした。 私の懸念はテンプレート文字列のCSSに関連していましたが、オブジェクトがオプションである場合、私はそれに反対するものは何もありません!

明らかに、JSSも完璧ではありません。再利用可能なサーバーで生成されたシートはキラー機能になるでしょう。スタイル付きコンポーネントはそれを何らかの形でサポートしていますか? 誰か知っていますか?

今のところ、サーバーで生成されたスタイルシートを削除し、クライアントにすべてのスタイルを再レンダリングするように強制するのはばかげていると感じています:(

@martinjlowmは私にはタイピングがあるように見えますか?
..。
参照: https ://styled-components.com/docs/advanced#style -objects
あなたは誇大広告を理解していないと言います...しかし、私はそれが得るすべての憎しみを理解していません。 🤷‍♂
感情とスタイル付きコンポーネントは、CSSスタイルオブジェクトIMOよりも大幅に改善されています

そうか! 私はそれがそのようなオブジェクトをサポートしていることに気づいていませんでした。 私の懸念はテンプレート文字列のCSSに関連していましたが、オブジェクトがオプションである場合、私はそれに反対するものは何もありません!

明らかに、JSSも完璧ではありません。再利用可能なサーバーで生成されたシートはキラー機能になるでしょう。スタイル付きコンポーネントはそれを何らかの形でサポートしていますか? 誰か知っていますか?

今のところ、サーバーで生成されたスタイルシートを削除し、クライアントにすべてのスタイルを再レンダリングするように強制するのはばかげていると感じています:(

また、タグ付きテンプレートリテラルも入力できることを明確にしておきたいと思います。 TypeScriptはそれらを無効として正しくマークし、言語サービスはオートコンプリートの提案などを提供します。

image

@サウスポー

感情とスタイル付きコンポーネントは、CSSスタイルオブジェクトIMOよりも大幅に改善されています

なぜReact開発者がこれに夢中になるのか私はまだ混乱しています。 CSSをテンプレート文字列に入れたい場合は、Angularを使用してHTMLもテンプレート文字列に入れてみませんか? Reactの強みは、JSX要素が実際にはJSオブジェクトであり、調査および変換するための強力な機能を備えていることです。これはJSSにも当てはまります。

JSの動きでCSSを推進しているのは、動的なことを行うためにJSがCSSよりもはるかに優れているという事実であり、JSオブジェクトの能力はその一部ではありません。

styled-componentsがオブジェクトをサポートしているという事実は、一種の赤いニシンです。

  • それらをサポートしますが、何らかの理由で「これは、既存のスタイルオブジェクトがあり、徐々にスタイル付きコンポーネントに移行したい場合に特に便利です」と述べています。 彼らは明らかにオブジェクトを操作できることの価値を認識しておらず、スタイルオブジェクトは常にAPIで二流市民として扱われるようです。
  • ドキュメントでは、JSSで次のような実際のCSSセレクターをサポートしているかどうかは明確にされていません。
{
  color: 'black',
  '&$error': {
    color: 'red'
  }
}

Emotionでさえ、スタイルオブジェクトの価値に十分な敬意を払い、それらをより一流の市民として扱います。

オブジェクトを使ってスタイルを書くことは、感情の核に直接組み込まれた強力なパターンです。

@lcswillemsは、これらすべての小さなHOCを常に作成するのがどれほど面倒であるかを過小評価しています(そして、ほとんどの自動インポートシステムは、 @material-ui/core/CardCardとしてインポートするかどうかを知るのに十分なほど賢くないという事実MuiCard (そして、まだインポートステートメントを手動で書いている場合は、時間を大幅に浪費しています))

const Card = styled(MuiCard)`
  display: flex;
`

const Details = styled.div`
  display: flex;
  flex-direction: column;
`

const CardContent = styled(MuiCardContent)`
  flex: 1 0 auto;
`

const CardMedia = styled(MuiCardMedia)`
  width: 151px;
`

この種のことは、各ラッパーとラップされたコンポーネントに名前を付ける方法を常に決定する必要があるため、ひどい決断疲労を引き起こします。

これは@dfernandez-asappが彼が言うときに話していることです:

(しばらくすると、Styled HOCがどこにでもあると、多くの余分な作業が追加され、それらのHOCが嫌いになりました...少なくともそれは私の個人的な経験です)

HOCはほとんど死ぬ必要があります。 これは廃止されたパターンです。 たとえば、 react-reduxuseSelectorフックで出てきました。これはconnect HOCよりも100倍便利です。ApolloはHOCからフックに移動しました。同じことがuseStylesにも当てはまります。このライブラリのwithStylesよりも便利です。

コピーして貼り付けたCSSをJSSに変換する手間は、はるかに解決可能な問題です。興味があれば、CSSまたはWebサイトを自動化するためのVSCode拡張機能を作成することもできます。

興味があれば、自動化するためのVSCode拡張機能も作成します

@ jedwards1211 paulmolluzzo.convert-css-in-jsがありますが、JSSのためにそれを改善できれば、それは歓迎されると確信しています。

ええ、私は間違いなくそれを改善できるように見えます、それはCSSプロパティのみを変換し、ルールとセレクターは変換しません。

@ jedwards1211私はあなたが言ったことを読みました、そしてこれから少し後退します-それはスペース上のタブの使用について議論する人々からのコメントを思い出させます。 現実には、それが最終的に有用な製品を生み出す限り、それはあなたが使用するものに実際には違いはありません。

TwitterまたはRedditにあなたの意見/ホットテイクを残してください、そして私たちはそこでそれらを議論することができます-しかし、CSSのテンプレート文字列とオブジェクトの無意味な炎の戦争でこの問題を脱線させ続けないでください...私たちは皆、私たちがより良いことに同意できると思いますそれより😄

MUIの現状を変更する価値がないことを指摘していただきありがとうございます。 😉

私の主な懸念は、Webpackバンドルがスタイル付きコンポーネントコードとJSSコードの組み合わせで肥大化するかどうかです。これは、アプリに既存のJSSが多すぎて、ヤンクアウトして他のものに置き換えることができないため、および/またはとにかく私たちのスタイルのためのJSS。

公平を期すために、私はタブとスペースを気にしませんが、作成するコンポーネントごとに5ダースのHOCを作成する必要がある場合、仕事を楽しむことはできません。 存在するすべてのツールには、有用な製品を作成する機能があります。 すべての場合に本当に完全に便利なものがあれば、生態系に絶え間ない変化はなく、これらの議論はありません。 ですから、あなたがそれについて考えるとき、それは本当に違いを生みます。

@ jedwards1211スタイル付きコンポーネントの使用を余儀なくされた場合でも、 v4に導入された代替のcss prop構文があります。少なくとも、この方法では心配する必要はありません。スタイル付きコンポーネント(MuiCard、StyledCardなど)にプレフィックスを付けます。

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

// CSS is separate from the markup 👍
const avatarStyle = css`
  width: 32px;
  height: 32px;
  border-radius: 50%
`;

// No wrappers, prefixes in the markup (such as <MuiAvatar>, <StyledAvatar> etc.) 👍
function SomeComponent(props) {
  return <div> ... <Avatar css={avatarStyle} /> ... </div>
}

@ jedwards1211スタイル付きコンポーネントを使用している場合は、例を次のように簡略化することもできます。

const Card = styled(MuiCard)`
  display: flex;

  ${MuiCardContent} {
    flex: 1 0 auto;
  }

  ${MuiCardMedia} {
    width: 151px;
  }
`

const Details = styled.div`
  display: flex;
  flex-direction: column;
`

@koistya cssプロップはちょっとクールですが、重要な注意点はBabelプラグインで実装されているため、すべての人、特にtscを使用してtsxファイルをコンパイルする人には向いていません。 また、TypeScriptまたは少なくともFlowが、コンポーネントにcssプロップがないと文句を言う原因になると思います。

私は主に、これが私のアプリに引き起こす可能性のある混乱について不満を持っていると思います。 @oliviertassinariは先日、MUI v5でstyled-componentsをデフォルトにすることを考えていると述べました。 そして、それがオプションであり、JSSを引き続き使用できることを願っていますが、それを実現できるかどうかを確認します。 それはショックでした-しかし、ユーザーベース全体の好みについて本当に徹底的な国民投票がありましたか? 今ではもっと人気があるので、どちらかといえばエモーションを期待していました。

また、TypeScriptまたは少なくともFlowが、コンポーネントにcsspropがないと文句を言う原因になると思います。

構成可能です。

しかし、ユーザーベース全体の好みに関する徹底的な国民投票は本当にありましたか?

不可能だよ。 私たちは、GitHubに従事している人々が「私たちの」ユーザーであると本当に想定することしかできません。 この問題は、私たちがこれまでに経験した中で最も賛成の問題です。

今ではもっと人気があるので、どちらかといえばエモーションを期待していました。

人気をどのように測定しましたか?

⚠️感情は、スタイル付きコンポーネントよりも開発者によって大幅に選択されていません(私が覚えているものから/ 6)。 npmでのダウンロードを検討する場合は、ストーリーブックを削除して、ダウンロード数を選択してください(膨大です)。

@ eps1lonは私が見ていたものです: https ://2019.stateofcss.com/technologies/css-in-js/

私は間違っていましたが、残念ながら、これは時間の経過に伴う人気のチャートではありませんが(非常に疑わしいチャートデザイン)、私が覚えていたのは上昇傾向のように見えることだけでした:
image

構成可能

TypeScriptにすべてのJSX要素がcssプロップをサポートしていると想定させる方法は実際にありますか? それを行うようにフローを構成する方法がわかりません。

編集:幸い、TypeScriptの方法を見つけましたが、Flowの方法があるかどうかはわかりません。

この問題は、私たちがこれまでに経験した中で最も賛成の問題です。

分かりました。 はぁ

styled-componentsの主な貢献者の1人であるFWIWは、型システムに対して不親切な態度をとっているようです。

https://github.com/styled-components/styled-components/issues/3012#issuecomment -583878486

TS / Flowユーザーの開発エクスペリエンスを気にかけているようであれば、スタイル付きコンポーネントに移行するというアイデアについて、私はもっと安心できるでしょう...

@ jedwards1211それが役立つ場合は、 cssのBabelマクロがあります。 特にcss/scss / lessから来ているので、誰もが「スタイル付き」の方法に移行するのが好きではないと思います。

しかし、目標は何ですか? パフォーマンスはどうですか? たとえば、一部のシステムはアトミックcssをサポートしています。 Tailwindsから来ると、物事がはるかにクリーンになり、おそらく高速になります。

@ hc-codersatlas packages/material-ui-benchmarkにいくつかのベンチマークがあります。

@koistya正しく読んだら、感情は他の人よりもずっと速く見えます。

@oliviertassinariほとんどの開発者は実際にこの選択を「行います」か? react-selectとstorybookについてのあなたの言及によると、ほとんどの開発者はUIコンポーネントとマテリアルにバンドルされているものを使用する可能性があります-uiは大きな1です。バンドルされているものがひどい場合を除いて、バンドルサイズと支出を増やすことはありませんUIフレームワークがすでに使用しているものに加えて、別のシステムでより多くの努力をします。

これらのUIフレームワークのほとんどは大企業のものです。つまり、実際にこの「選択」を行っている人は少数です。

たとえば、グロメットはスタイル付きコンポーネントを使用します。これは、多くの企業が1つの時点で使用していた/使用していたものです。

そしてその点で、npmダウンロードはどういう意味ですか? 企業での使用は、ファイアウォールと内部npmキャッシングを意味する可能性があり、これらのメトリックを歪めます。

変更がある場合は、人気のようなものではなく、技術的なメリットに基づいてベスト1に変更してください。 私は、material-uiが任意のライブラリを使用する場合、mui自体が最も人気のあるuiフレームワークの1つであるため、人気のある1になると予測しています。

image

@ South-提案された簡略化は機能しません。 MuiCardContentはスタイル付きコンポーネントではないため、例で${MuiCardContent}を使用することはできません。

https://styled-components.com/docs/advanced#referring -to-other-components

基本的に、個々のHoCラッパーをすべて回避する方法はありません。 しばらく考えてみましたが、基本的にはJSSで行うのと同じ量のタイピング/名前付けの決定であることに気付きました。

@mbrookes @oliviertassinari条件付きスタイルと内部コンポーネントスタイルはどのように処理されますか?
たとえば、次のstyled-componentsベースの同等物は何でしょうか?

// conditional class name
<MenuItem classes={{selected: classes.selectedItem}}>...</MenuItem>

// inner component class name
<Dialog classes={{paper: classes.dialogPaper}}>...</Dialog>

styled-componentsに切り替えるという考えについては落ち着きましたが、APIは非常に異なるか、依存する必要があると想定しているため、これらの種類のユースケースを処理するための確実な計画があることを確認したいと思います。 BEMスタイルのクラス名。

@jedwards1211ああ私の間違い。 この例は、スタイル設定されたコンポーネントであるという印象を受けましたが、実際には、そうでない場合は機能しません👍

@ jedwards1211 clsxは、過去に条件付きクラスのスタイル付きコンポーネントと組み合わせて見たものです。そのような意味ですか?

私が現在行っているプロジェクトでは、必要に応じてMUIコンポーネントをラップするスタイル付きコンポーネントを使用しているため、MUIの条件付きスタイリングを使用していません。

@ South-Paw that(またはclassnames )はソリューションの内部詳細である可能性がありますが、 styled-componentsラッパーは単一のclassName AFAICTのみを注入するため、いくつかのオーバーライドクラス名をコンポーネントに渡すための便利な方法ではありません。 代わりに、 <Dialog Paper={StyledPaper}>...</Dialog>のようなことをしなければならないかもしれませんが、選択したMenuItemクラスの例がどうなるかさえわかりません。

@ jedwards1211簡単な例を挙げて、あなたが説明しているユースケースが何であるか、そして問題がどこにあると感じるかをよりよく理解できるようにする時間がありますか? 解決策を試してみたいのですが、これが何に当てはまるのかまだわかりません😄

ええ、今夜は時間切れですが、明日は時間切れです。
また、 jss-codemorphsの作業が進行中であり、最終的には、貼り付けられたCSSをJSSに変換するためのVSCode拡張機能を作成することを計画しています。

この提案のファンではなく、スタイル付きコンポーネントの構文やパッケージの保守方法のファンではありませんでした。 マテリアルUIについて私が最も気に入っていることの1つは、現在のスタイリングソリューションです。

FacebookがCSS-in-JSソリューションもオープンソーシングしている可能性があることを読んだのは興味深いことです。 それが出てきたときにそれも見てみるのは価値があるかもしれません。

手元の実際のトピックについて。 Typescriptの経験があまり良くないので、私はスタイル付きコンポーネントが嫌いです。 多くの場合、タイプは支援よりも害を及ぼします。 コンパイル時間が遅く、インターフェイスが非常識です(インターフェイスを介してスタイル付きコンポーネントがどのように機能するかを理解しようとすると、ネストされたPickの魔法が原因で、悪夢になります)。 styled-componentsにこのタイプのDXがある限り、material-uiがこれを採用するのは一歩後退したように感じます。

FacebookがCSS-in-JSソリューションもオープンソーシングしている可能性があることを読んだのは興味深いことです。

@venikxそれはどのくらい起こりそうですか? それがhttps://reactpodcast.simplecast.fm/75にあることを示唆するかもしれない何かについて私が最後に聞いたとき、それは5年の長い目標であるように思われました。

うわー、本当に? 彼らがすでに「タイムライン」を提供していることを私は知りませんでした。 どういうわけか、並行モードと同時に発生すると思いました。 残念な。

そうは言っても、スタイル付きコンポーネントについての私の主張は今も続いています。 私は、スタイル付きコンポーネントを使用するのではなく、純粋なマテリアルUIのスタイル処理方法を使用することを好みます。 styled-componentsからの型付けは、コンパイラー用であり、ドキュメント用ではないようです。

もう1つの厄介なこと(ただし、これもおそらく個人的な好みです)は、コンポーネントにスタイルを動的に適用する方法です。 そのロジックをスタイル付きコンポーネントに埋め込むよりも、classNameを追加または削除する方が非常に好きです。

Material-ui apiは、現時点では本当にきれいです。

Typescriptの経験があまり良くないので、私はスタイル付きコンポーネントが嫌いです。

私はこれまでに少なくとも4つの大規模なプロジェクトでstyled-componentsとTypescriptを一緒に使用しており、タイプに問題はありませんでした-コンポーネントライブラリで何かを行うときは少し厄介かもしれませんが、それはMUI側にあります-消費者側ではありません。

コンパイル時間が遅い

私が取り組んだプロジェクトでこれを使用したことはありません-あなたが意味することのどこかに例がありますか?

非常識なインターフェース(スタイル付きコンポーネントがインターフェースを介してどのように機能するかを理解しようとすることは、ネストされたすべてのピックマジックのために悪夢です)

なんらかの方法で@typesプロジェクトを改善できると思われる場合は、@ typesプロジェクトへの貢献を検討することもできます。現在のプロジェクトよりも改善されていれば、誰もがそこでの作業に感謝すると思います。

そのロジックをスタイル付きコンポーネントに埋め込むよりも、classNameを追加または削除する方が非常に好きです。

styled-componentsでクラスを使用することを妨げるものは何もありません。

const Box = styled.div`
  height: 160px
  width: 160px;
  background-color: black;

  .red {
    background-color: red;
  }
`;

// simple usage
<Box className="red" />

// get more complex with conditionals and using something like clsx (https://www.npmjs.com/package/clsx)
const isRed = true;
<Box className={clsx({ red: isRed })} />

いくつかのコメントがそうではないと主張しているにもかかわらず、親の問題には150👍と27🎉があり、18👎と9😕しかないことに注意してください。 この議論を嫌う声の少数派と、それが前向きな一歩だと思う多数派がいるようです🤷‍♂

@ South-投票の問題は、JSSとstyled-componentsの唯一の選択肢であるということです。 ボーカルの部分は、スタイル付きのコンポーネントが好きではなく、JSSが好きではないということです。 多分投票なら

結局のところ、JSSよりも優れているものは何でもあります。 古いです。 遅くてかさばる(バンドルサイズ)ので、次に移動する必要があります。 したがって、投票はあなたの結論をまったく支持しません。

誰が議論に勝つかを確認するために互いに戦っている人々についてのノイズでこの問題を満たさないSpectrumチャットまたは何かに移動できますか?

コアチームからのこのトピックに関するディスカッションのスレッドをフォローしています。

あなたはコアチームの判断を過小評価していると思います。個人的には、このトピックについて議論するのをやめ、コアチームをもっと信頼するべきだと思います。 結局のところ、マテリアルUIの方向性を決定するのはコアチーム次第です。

あなたが本当にそれについて強く意見を持っていると感じるなら、Material UIは驚くほどMITライセンスを受けており、それをフォークして、あなたが持っているビジョンを継続します。そうすることをお勧めします。将来、多様な環境から学ぶかもしれません。

しかし、お願いします。コアチームに仕事を任せて、信頼してください。彼らは本当に素晴らしいスキルを持った有能な人々だからです。

ここに見るべき美しいものがあります

image

結局のところ、JSSよりも優れているものは何でもあります。 古いです。

@ hc-codersatlas old==成熟した-なぜそれが問題になるのか詳しく説明していただけますか?

OKはホットな問題のようですが、誰かがこの簡単な情報を確認できますか:現在のMuiバージョン(4または5)で、CSSのように見えるタグ付きテンプレートリテラルでstyled-componentsのような構文を使用することは現在可能ですか? ?
この質問に対する明確な「はい」または「いいえ」の答えは見つかりませんでした。 基盤となるテクノロジーについてはあまり気にせず、開発者の利便性だけを気にします。 InVisionからCSSをコピーして貼り付けると、基本的に非常に便利な場合があります。

この問題は、Material-UIで使用されるスタイリングソリューションに関するものです。質問は、アプリのスタイル設定/コンポーネントのスタイル変更方法に関するもののようです。どのソリューションでも使用できます。

https://material-ui.com/guides/interoperability/

JSSは、プラグインとしてテンプレートリテラルを基本的にサポートしています。

非常に包括的なCSSからJSSへのコンバーターの実装が完了しました。

うまくいけば、CSSをJSSスタイルにコピーして貼り付ける手間を省くことができます。

@jedwards1211これを参照してください
https://css2js.dotenv.dev/

@nainardev他のユーティリティは非常に制限されており、CSS属性を変換しますが、セレクター、ネストされたセレクター、アニメーションキーフレーム、メディアクエリなどは変換しません。そのため、ツールを非常に包括的にしたため、変換できます。うまくいけば、あなたがそれに投げる本格的なCSS。

どこかでこの答えを見逃したかもしれませんが、とにかくそれを上げたいと思います。 現在、マテリアルUIコンポーネントへの移行と、スタイリングソリューションの評価を行っています( less vs makeStyles vs styled-components )。ほとんどのスタイリングは、より少ない方法で行われます。ファイルと新しいMUIコードのほとんどはmakeStylesを使用していますが、これはv5の一部になるため、スタイリングに関する技術的負債を減らすために何ができるでしょうか。

  1. makeStylesはv5に含まれますか? styled-componentsとテーマでどのように機能しますか? たとえば、これはstyled-componentsでどのように表示されますか?
const useStyles = makeStyles((theme) => ({
  paper: {
    padding: theme.spacing(2),
    textAlign: 'center',
    color: theme.palette.text.secondary,
  },
}));
  1. (v4)これよりもスタイル付きテンプレート文字列でthemeオブジェクトを取得するためのより良い方法があるので、複数回使用できますか?
const StyledContainer = styled.div`
  color: ${({ theme }) => theme.palette.primary.main};
  padding: ${({ theme }) => theme.spacing(1)};
  background-color: ${({ theme }) => theme.palette.background.paper};
`;
  1. makeStylesがv5に存在すると仮定すると、大規模なコードベースにstyled-componentsテーマプロバイダーとMaterial UIテーマプロバイダーの両方を使用している場合、パフォーマンスが低下することを期待する必要がありますか?

Material UIを使用するのが大好きです、すべてのハードワークに感謝します!

@egilsster

  1. はい、@ Material-ui/stylesまたはreact-jssのいずれかから表示されます。
  2. はいhttps://material-ui.com/guides/interoperability/#theme
const StyledContainer = styled.div`
  ${({ theme }) => `
  color: ${theme.palette.primary.main};
  padding: ${theme.spacing(1)};
  background-color: ${theme.palette.background.paper};
  `}
`;
  1. 主な問題は、1。構成のオーバーヘッド、1回のコスト、2。2つのCSS-in-JSランタイムのロードです。 / result?p = @ sentry/browser。

迅速な返信をありがとう、非常に感謝します。

  1. はいmaterial-ui.com/guides/interoperability/#theme

これはかなりクールです。 いくつかの回避策はおそらくこれに従うでしょう、私が移行しているプロジェクトはTSを使用していませんが、VSCode /言語サーバーはこの場合themeが何であるかを知らないようで、 styled-componentsを失います構文の強調表示も。

改めて感謝します、この開発を続けていきます。

@oliviertassinariスタイル付きコンポーネントへの移行がある場合、それは<ListItem classes={{ selected: myCustomClassName}}>のようなCSS APIに依存できなくなったことを意味しますか?

@ jedwards1211 classes APIはそのまま残ります。

わかった。 スタイル付きコンポーネントはルート要素に単一のクラスしか適用できないため、MUIがスタイル付きコンポーネントを内部でどのように使用するかについて少し混乱しています。

const MyRoot = styled('div')`
  // some nice styles
`;

const MyAwesomeChild = styled('div')`
  // some nice styles
`;

export function AwesomeRoot(props) {
  return (
    <MyRoot className={props.classes?.root}>
      <MyAwesomeChild className={props.classes?.child}/>
      {props.children}
    </MyRoot>
  );
}

それは意味がありますか@jedwards1211

@yordis簡単そうに見えますが、 https://github.com/mui-org/material-ui/blob/master/packages/material-ui/src/Button/Button.jsのような複合セレクターをどのようにリファクタリングしますか

styled-componentsを使用してこの既存の動作を維持する方法を実際に考えることはできないため、人々が予想するよりも多くの重大な変更を引き起こす可能性があります。

  outlined: {
    '&$disabled': {
      border: `1px solid ${theme.palette.action.disabledBackground}`,
    },
  },

既存のコードと人々のカスタムオーバーライドは、場合によってはCSSの特異性にも依存している可能性があります。

多分これ? これは私にとって基本的なことだと感じているので、フォローするかどうかはわかりません。おそらく、コンテキストや情報が不足しています。

const MyOutlinedComponent = styled('div')`
  ${props.disabled && `
      border: `1px solid ${({ theme }) => theme.palette.action.disabledBackground}`,
  `}
`;

<MyOutlinedComponent disabled/>

@yordisおそらく。 私が言ったように、人々はおそらくこれがユーザーにどれだけの重大な変更をもたらすかについて考えていませんが、その例が重大な変更を妨げるとは思いません。

実際の例と実際の潜在的な破壊的な変化を共有していただけませんか?

強いケースを共有しないと、あなたをフォローするのは難しいです。 あなたのメッセージに基づいて、あなたはこのトピックを完全に理解していないと思います、または私は間違った判断をしているかもしれません。 私が間違っているかもしれない、私が理解するのを手伝ってください。

@oliviertassinariテーマのオーバーライドは、v5で変更しなくても機能しますか? 次のオーバーライドの例が機能するためには、MUIは、 styled-components生成されたルートクラス名に加えて、JSSで生成されたクラス名を適用する必要があるようです。

const theme = createMuiTheme({
  overrides: {
    MuiButton: {
      root: {
        '&$disabled': {
          color: myCustomColor,
        },
      },
    },
  },
});

@yordisはそれについてもっと考えて、 classesプロップを介して渡されたスタイルの複合セレクターが幸運にも機能することに気づきました。 ただし、テーマのオーバーライドスタイルについてはよくわかりません。

私は、style = {object}を使用してスタイル設定されたプレーンなMUIだけでなく、MUI上で両方のスタイル設定されたコンポーネントを使用できることを嬉しく思います。

50枚のカードを含む結果リストページを作成します。各カードには、メディアカルーセル、情報、クリックハンドラー、ボタンなどが含まれています。

スタイル付きコンポーネントを使用すると、レンダリング時間が約0.5秒長くなります。 const useStyles = makeStylesまたはstyle={object}と比較して。

このロードマップ計画の結果を受け入れる必要があります。 しかし、完全にトップダウンで他の何かをオーバーライドできない場合は、UIの採用計画に間違いなくねじれが生じます。

@Icehunterは、結果とサンプルプロジェクトをオンラインで投稿して、人々に見てもらうことができますか?

@Icehunterは、結果とサンプルプロジェクトをオンラインで投稿して、人々に見てもらうことができますか?

サンプルプロジェクトは、プロプライエタリコードをコンテナ化するので難しいでしょう。 レンダリングされた画像とパフォーマンスタブのタイミング結果セクションをすぐに投稿します。

50枚のカードを含む結果リストページを作成します。各カードには、メディアカルーセル、情報、クリックハンドラー、ボタンなどが含まれています。

@Icehunterはそれらのスタイルに小道具を送っていますか? 50枚のカードでも500枚のカードでも、生成されるクラスの数は同じである必要があります。 特定の例に共有できない独自のコードが含まれているように聞こえますが、共有できるコードでこの問題を再現することは可能でしょうか?

styled() / styled.div APIは、_every_要素のレンダリングにオーバーヘッドを追加するため、クラス名をキャッシュしても速度が低下する可能性があります。 makeStylesを使用すると、スタイルのグループを一度アタッチしてから、クラス名を手動で適用することができます。これは、多くの場合、大幅に高速です。

コード化されたコンポーネントstyledに依存するソリューションは、MUI makeStylesよりも3〜4倍遅くなる可能性があることを示すために、 CodeSandboxの例をまとめました。
image

styled APIは便利ですが、リスト/テーブルで頻繁に使用するとパフォーマンスの問題になる可能性があるという@Icehunterの感情を反映しています。 バックアップとしてmakeStylesがあると便利です。

@schnerdこれらの例をまとめてくれてありがとう、それは懸念を本当によく示しています。 補足として、投稿の前に「見るのは難しくありません...」と考えるのと同じように、見下すようなものとして外れる可能性があり、それ以外の優れた例のセットには実際には追加されませんでした

@tuxracer謝罪–更新されました。

@Icehunterそれが何を意味するのかわかりませんが、SCまたはJSSで一般的なスタイルを使用しましたか?

@Icehunterそれが何を意味するのかわかりませんが、SCまたはJSSで一般的なスタイルを使用しましたか?

実際には両方。 最終的にmakeStylesを使用しましたが、それまたはstyled = {object}を使用すると、同じパフォーマンス結果が得られました。

コンポーネントライブラリ全体とメインサイト全体のパフォーマンスを向上させるために、移行プロセスを進めています。

スタックに関しては、nextjsで記述されています。

明確にするために(編集):

私は意図したとおりにSCを使用し、muiコンポーネントをラッピングしました。 非常に遅いことが判明しました。

次に、共有ファイル設定のmakeStylesやstyle = {object}、およびローカル(シミュレートされたカスケード)を使用してmuiコンポーネントを使用しました。 はるかに高速です。

このアイデアをまったくブロックしたくありません。 ただし、デフォルトの場合。 次に、デフォルトの選択をグローバルにトップダウンでオーバーライドし、独自の選択を適用する方法があるはずです。

多分これ? これは私にとって基本的なことだと感じているので、フォローするかどうかはわかりません。おそらく、コンテキストや情報が不足しています。

const MyOutlinedComponent = styled('div')`
  ${props.disabled && `
      border: `1px solid ${({ theme }) => theme.palette.action.disabledBackground}`,
  `}
`;

<MyOutlinedComponent disabled/>

多分私はこのゲームに遅れる。 しかし、 @ jedwards1211は、これをSCで表現する方法を探していると思います: https ://codesandbox.io/s/magical-snow-5bzd8

私自身はこれをいくつかの場所で持っています。 その日が来たときにこれをv5に移行するのが簡単だったらいいのにと思います

実際、このようなものがスタイル付きコンポーネントを使用してどのように機能するかはわかりません。

たとえば、マテリアルUIが将来Typographyのデフォルトのバリアントのオーバーライドをサポートする場合、JSSはスタイル付きコンポーネントよりも簡単だと思います。

@ heb-mmここに詳細なRFCがあり、@ oliviertassinariが3月7日にこのスレッドについて言及しました。

上にスクロールして言及を見るのに1分もかかりませんでした。

編集:疑問に思っている人のために、heb-mmはコメントを削除しました。

コード化されたコンポーネントstyledに依存するソリューションは、MUI makeStylesよりも3〜4倍遅くなる可能性があることを示すために、 CodeSandboxの例をまとめました。

@schnerdベンチマークを更新してMaterial-UIの社内styled apiを含めました。これは、 styled-componentsを模倣する必要があります。 他のオプションと比べて信じられないほど遅いのを見て驚いた。 https://codesandbox.io/s/css-in-js-comparison-ljtjz?file=/src/App.jsを参照してください

image

@emotion/styled (基本的にstyled-componentsと同じAPIを持っている)が同じくらい遅いかどうか誰かが知っていますか? それらの実装について、より最適化されている可能性があるものがあるかどうか疑問に思っています。

@emotion/styled (基本的にstyled-componentsと同じAPIを持っている)が同じくらい遅いかどうか誰かが知っていますか? それらの実装について、より最適化されている可能性があるものがあるかどうか疑問に思っています。

https://codesandbox.io/s/css-in-js-comparison-sej1m

image

スタイリングされたコンポーネントとほぼ同じ速度です。 それでもmakeStylesほど速くはありません。 ほとんどの場合、私が目にする問題は、オブジェクトの作成とオブジェクトのキャッシュ/メモ化の違いです。

うーん、これはMUIへの移行計画をかなり混乱させる可能性があります。 CSS、テーマ、パフォーマンスの管理で多くの問題が発生した後、現在styled-componentsからMaterialUIスタイリングシステムに移行しています。 styled componentsは最初は問題ありませんでしたが、その上に独自のテーマソリューションを構築しましたが、UIが大きくなると、CSSも大きくなりました。 TypeScriptを使用しているため、インラインCSS文字列の代わりにJSオブジェクトを簡単にリファクタリングできるという事実は、大きなセールスポイントでした。 😕

だから私はMaterialUIにかなり慣れておらず、v5のアルファリリースも見たばかりです。 @ ldiego08あなたが言った:

現在、スタイルコンポーネントから離れて、マテリアルUIスタイリングシステムを採用しています。

私は通常、reactで作業するときにスタイル付きコンポーネントを使用します。 マテリアルUIスタイリングシステムとは何ですか?また、今後マテリアルUIでスタイルとCSSを使用するための推奨される方法は何ですか? 私はこのページを読みましたが、CSS-IN-JSに賛成かどうかはわかりません: https://material-ui.com/system/basics/。 私は通常、オブジェクト構文ではなくCSSを作成することを好みます。「通常のcss構文」を使用できるようになるだけでなく、JSの機能も手元にあるため、CSS-IN-JSを使用する利点を享受しています。

始めるために助けてくれてありがとう!

styled-componentsAPIがなぜそれほど人気が​​あるのか​​わかりません。 速度は遅く、クラス名を生成するだけでなく、すべてをコンポーネントにラップする必要があります。 また、タグ付きテンプレートリテラルとは何ですか? cssファイルにcssを書きたくなかったのは、javascript文字列で書く方がはるかに良いからです。 :Dオブジェクト構文は、構成やリファクタリングなどに関してははるかに強力です。私にとって、cssオブジェクトを受け取り、クラス名を返すプレーンエモーションcssおよびcx関数は、最も柔軟で強力なAPIです。 したがって、感情を込めてクラス名を生成し、クラスAPIを使用するだけで、非常に柔軟で強力になります。 ですから、なぜパフォーマンスと柔軟性を「より便利な開発者API」と交換するのかわかりません(一部の人にとっては、それはひどいAPIです)。

styled-componentsAPIがなぜそれほど人気が​​あるのか​​わかりません。 速度は遅く、クラス名を生成するだけでなく、すべてをコンポーネントにラップする必要があります。 また、タグ付きテンプレートリテラルとは何ですか? cssファイルにcssを書きたくなかったのは、javascript文字列で書く方がはるかに良いからです。 :Dオブジェクト構文は、構成やリファクタリングなどに関してははるかに強力です。私にとって、cssオブジェクトを受け取り、クラス名を返すプレーンエモーションcssおよびcx関数は、最も柔軟で強力なAPIです。 したがって、感情を込めてクラス名を生成し、クラスAPIを使用するだけで、非常に柔軟で強力になります。 ですから、なぜパフォーマンスと柔軟性を「より便利な開発者API」と交換するのかわかりません(一部の人にとっては、それはひどいAPIです)。

私は同じ懸念を持っていました:)おそらくそれは物事を少しクリアします:
https://github.com/mui-org/material-ui/issues/6115#issuecomment -580449539

@martinjlowmはい、同じページにいます:)マテリアルUIチームに行く最も賢い方法は、ある種のプラグ可能なソリューションを実装し、jsソリューションのcssと組み合わせないことで、人々が何を使用するかを選択できるようにすることだと思います。その方法でバンドルサイズを節約します。 また、クラスとcreateMuiTheme APIを保持します。これは、その最も強力な部分だからです。 私にとって、jsのcssは、コンポーネントの状態に基づく簡単な動的スタイリング、cssまたはコンポーネント全体(オブジェクトアプローチが優れている場所)のリファクタリングまたは削除時の信頼性、パフォーマンス(外部スタイルシートの束から未使用のスタイルの束をダウンロードしない)に関するものです。 、など。繰り返しになりますが、なぜ人々がエディタを強調表示して文字列を書くのが好きなのかわかりません。 つまり、コンテキストから小道具にアクセスするには、${}を使用する必要があります。 background od div要素を設定するよりも複雑な場合、そのアプローチは厄介で、私の意見では読みにくいです。 私はそれをバッシングしているのではなく、私が考えていることを言って、すべての開発者がスタイル付きコンポーネントを好むわけではないことを証明しようとしています。 :)

@vdjurdjevic確かに、jsソリューションでmaterial-uiを1つのcssに結合することは、css-in-jsのプラクティスが必然的に異なる方向に成長する場合の競合のほぼ確実なレシピです。

特定のcss-in-jsプロバイダーでスタイリングを適用するアダプターパターンはどうですか? スタイル自体は、material-uiパッケージ内で一貫した形式で定義する必要があります。 対応するアダプターによって異なる方法で実行されるのは、これらのスタイルの適用です。

次のようなもの:

import {EmotionAdapter, StyledComponentAdapter, ThemeProvider} from "@material-ui/core/styles";
...
return 
    (<ThemeProvider theme={theme} adapter={EmotionAdapter}>
        ...
    </ThemeProvider>)

@vdjurdjevichttps : //github.com/mui-org/material-ui/issues/6115#issuecomment-652762320に関するあなたの考えにほぼ同意します。 私が最近https://github.com/mui-org/material-ui/issues/16947#issuecomment-653797178で共有した方向性のこの要約が気に入るかもしれません。

エディターを強調表示して文字列を書くのが好きな理由がわかりません

私の観点からのいくつかの理由:

  • React.createElement('div', {})を書かない理由に近い。
  • Web開発の経験が限られている人(多くの人)はJavaScript APIを学ぶのに苦労していますが、CSS構文の方が簡単だと感じています。 例としてデザイナーを取り上げ、チームのデザイナーにそれについてどう思うか聞いてみましょう:)。
  • 開発ツールとソースの間でコピーアンドペーストできません(これは嫌いです)。

@oliviertassinariわかりました、これらはいくつかの確かな点です、私は同意します:)それでも、私(デザイナーでも、初心者でも、上級開発者でもない)にとって、スタイル付きコンポーネントとタグ付きテンプレートリテラルは決してオプションではありません。 今後の開発の方向性について要約を読みましたが、cssエンジンはオプションになると聞いてうれしく思います。 それを切り替えることができる限り、デフォルトとしてスタイル付きコンポーネントを気にしません(それが大多数のユーザーが好きな場合)。 そして正直なところ、次のプロジェクトではv4を使用したJSSに固執すると思います。これには、いくつかの優れた機能(プラグインの拡張や作成など)があります。 私は感情のためにstylisプラグインを書かなければなりませんでした。

PS。 私もJSXのファンではありません:)すぐに面倒になり、矢印コードになってしまいます。動的要素をレンダリングする必要があるコンポーネントの場合は、createElementを使用するしかありません。 createElementを直接操作する方が良いと言っているのではなく、JSXは理想的ではないと言っているだけです。 私の意見では、Flutterは最高のDXを持っています。いつか、Webプラットフォームをうまく処理できるようになることを願っています。

@oliviertassinari https://github.com/mui-org/material-ui/issues/6115#issuecomment -643398897に記載されているように、進行中のパフォーマンステストによると、人気があるため、マテリアルチームがスタイル付きコンポーネントを選択するだけではないことを願っています。 遅いです。 いつもされています。 個人的には、CSSのJS表記などを学ぶ必要があるのは開発者であるという点です。

それは仕事の一部です。

開発者の生活を楽にすることは、パッケージメンテナーとしての私たちの仕事の一部です(私が話している私自身のプロジェクトの場合)が、それを簡単にすることとパフォーマンスを上げることの間には線があります。

そのため、私はmakeStylesのみを使用し、導入されてから常に使用しています。

私の最後のチームアーキテクトは、スタイルを設定されたコンポーネントに耳を傾けず、先に進んでいませんでした。現在、サイトは低速です。 テストブランチでmakeStylesに切り替えて、モバイルデバイスのTTIを50%(10秒)節約しましたが、そのコメントで述べたように、JS表記は誰にも知られていないため、受け入れられませんでした。

内部的には、マテリアルは必要なものを選択できますが、デフォルトでパフォーマンスを向上させてください。

[質問はStackOverflowに移動しました。]

@haysclark RFCに取り組むのではなく、サポートの質問にStackOverflowを使用してください。

@haysclark RFCに取り組むのではなく、サポートの質問にStackOverflowを使用してください。

@mbrookesヘッズアップをありがとう!

@emotion/styled (基本的にstyled-componentsと同じAPIを持っている)が同じくらい遅いかどうか誰かが知っていますか? それらの実装について、より最適化されている可能性があるものがあるかどうか疑問に思っています。

https://codesandbox.io/s/css-in-js-comparison-sej1m

image

スタイリングされたコンポーネントとほぼ同じ速度です。 それでもmakeStylesほど速くはありません。 ほとんどの場合、私が目にする問題は、オブジェクトの作成とオブジェクトのキャッシュ/メモ化の違いです。

Boxコンポーネントのパフォーマンスをプロファイリングと比較するとどうなるのか疑問に思い、Chakra-UIのBoxを適切に追加したところ、結果は...驚くべきものでした:P
https://codesandbox.io/s/css-in-js-comparison-forked-mg3gx?file=/src/App.js

image

@NvveenはChakra-UIv1を試しましたか? それは書き直されており、うまくいけばもっと良くなるはずです。 まだベータ版ですが、感情v11もあります。

@NvveenはChakra-UIv1を試しましたか? それは書き直されており、うまくいけばもっと良くなるはずです。 まだベータ版ですが、感情v11もあります。

最新のRCで試してみましたが、目立った違いはありません。 それでも通常のSCの約1.5倍から2倍遅いです。 私にとって最大の質問は、なぜMUIボックスがとても遅いのかということです。

@NvveenはChakra-UIv1を試しましたか? それは書き直されており、うまくいけばもっと良くなるはずです。 まだベータ版ですが、感情v11もあります。

最新のRCで試してみましたが、目立った違いはありません。 それでも通常のSCの約1.5倍から2倍遅いです。 私にとって最大の質問は、なぜMUIボックスがとても遅いのかということです。

Jssを使用しています。 SCは少なくともいくらか優れています。

私のマシンでは、テストケースが実行される順序が結果に影響を与えます。 比較

  1. ボックスファーストhttps://codesandbox.io/s/css-in-js-comparison-forked-tqlg1?file=/src/App.js
    Capture d’écran 2020-08-16 à 19 49 55

  2. ボックスの最後のhttps://codesandbox.io/s/css-in-js-comparison-forked-js6th?file=/src/App.js
    Capture d’écran 2020-08-16 à 19 49 45

@oliviertassinariガベージコレクションとv8からのjitが原因です。 テストの実行を実際に分離/分離することをお勧めします。 後のテストの方が優れていますが、ガベージコレクションがトリガーされることがあります。

Emotion、SC、Chakraはすべて、各小さなコンポーネントに独自のマウントスタイルがあり、MUIスタイルがまだ完全に最適化されていない場合の、理論上の最大パフォーマンスに近いようです。 それよりも優れたパフォーマンスを得る唯一の方法は、makeStyles / pure CSSのように、コンポーネントツリー全体に対して1つのスタイルシートを用意することです。 感情やSCなどの追加の30ミリ秒は、スタイルがマウントされていることを確認する必要がある各小さなコンポーネントの避けられないオーバーヘッドだと思います。

@ jedwards1211 dxを維持する場合、Atlassianはそれをcssにコンパイルするlibを作成しました。これはcompiledと呼ばれます。

このページは役に立ちましたか?
0 / 5 - 0 評価