web-dev-qa-db-ja.com

スタイル付きコンポーネントvs SASS（SCSS）またはLESS

ReactJS Boilerplateに出会いました。このBoilerplateは優れた担当者を持ち、コミュニティ主導です。スタイル設定セクションでは、スタイル設定されたコンポーネントCSSをより強調しましたが、従来のCSSスタイル設定方法への切り替えを止めませんでした。これは、Styled-Component CSSを際立たせるものと、なぜそれを採用する必要があるかということに興味を引きましたが。

私の理解 スタイル付きコンポーネントCSS ：

  1. コンポーネント駆動型のアイデア。 CSSもコンポーネントになりました。 -これはかなりクールです！
  2. 必要なものをロードし、必要なときにちょっと怠zyなCSSをロードする
  3. テーマプロバイダー、スキン、モジュール性、動的-これは他のライブラリでも実現できます
  4. コンポーネントDOMのサーバー側の構築とそのスタイル。

私の質問は：

  1. ブラウザは、JavaScriptの解析とは別にCSSを解析するように進化しました。なぜこれから逸脱して、すべてをJavaScriptに収めようとしているのですか？

  2. スタイル付きコンポーネントCSSは、クライアント側にJavaScriptライブラリを出荷します。クライアント側は、実行時にスタイルを実際に解析し、各コンポーネントがオンデマンドでロードされるときに<style />タグ内に配置します。これは、余分な負荷とロジックが最終的にブラウザの実行サイクルに寄与することを意味します。なぜこれが必要なのですか？

    （上記の質問により、ロードされたすべてのコンポーネントについて、対応するCSSが計算され、styleタグを介して頭に挿入され挿入されます/複数のスタイルタグ-CSSインタプリタの再発明）

  3. Headタグの<style />を介した連続した計算スタイルテキストのバンギングは、ブラウザーのリフロー/再描画を引き起こしますか？

  4. これから得られるパフォーマンス上の利点は何ですか？

コミュニティ、私のために空気をきれいにするか、私が間違っている場合は私を修正してください。

CSSスタイルが変更された場合、ブラウザのパフォーマンスがどのように高くなるかを再ペイントまたはDOMリフローについて説明するいくつかの良い記事。

cssreactjssassstyled-componentsreflow
20
Nirus

ブラウザは、JavaScriptの解析とは別にCSSを解析するように進化しました。なぜこれから逸脱して、すべてをJavaScriptに収めようとしているのですか？

JavascriptとHTML（つまりJSX）の両方を混合してから、CSS（JSSまたは別の）も混合すると、コンポーネントが単一のファイルに収まる堅固なモジュールになります。スタイルを別のファイルに保存する必要はもうありません。

次に、機能的な魔法が発生します。JSXは「HTML」を返す生データの純粋な関数であるため（実際にはそうではありません）、CSS-in-JSが「CSS」を返す純粋な関数または生データと同様に）。この時点から、 JSXについて読む および CSS-in-JSについても読む に値すると思います。

スタイル付きコンポーネントCSSは、クライアント側にJavaScriptライブラリを出荷します。クライアント側は、実行時にスタイルを実際に解析し、各コンポーネントがオンデマンドでロードされるときに<style />タグ内に配置します。これは、余分な負荷とロジックが最終的にブラウザの実行サイクルに寄与することを意味します。

実行時だけでなく。 CSS-in-JSSはCSSを返すデータの単なる関数であるため、どのプラットフォームでも使用できます。 Nodeを取得し、 [〜＃〜] ssr [〜＃〜] を追加すると、応答本文でブラウザにstyle要素が配信されます。したがって、 CSSを配信する元のケース。

なぜこれが必要なのですか？

開発で便利なため、ReactまたはRedux、jQueryと同様、他のライブラリと同様に、ネットワーク負荷とブラウザーのパフォーマンスコストが発生します。

それは問題を解決するので、あなたはライブラリを取ります。問題ないようであれば、なぜライブラリを使用するのですか？

Headタグの<style />を介した連続した計算スタイルテキストのバンギングは、ブラウザーのリフロー/再描画を引き起こしますか？

リフローを強制する非常に多くのもの があります。

ブラウザはスマートです。スタイルが変更されていない場合、彼らは再描画することさえ試みません。これは、差を計算しないという意味ではなく、CPU時間を消費します。

スタイル（再）計算の範囲と複雑さ には良い入門書があります。主題をより深く理解するのは読む価値があります。

1
Fleischpflanzerl

私は長年SCSS（SASS）を使用しており、Styled-Componentsいくつかのプロジェクトで、いくつかは大規模。

私は両方が大好きで、Styled-Components私にとって、一歩前進したような気がします：

スタイル付きコンポーネント-長所

  1. 完全なスタイリングの分離;あるチームメンバーが別のチームメンバーのスタイルをオーバーライドできない場合に、チームで作業するときに潜在的なバグを防ぎます。
  2. 自動生成されるクラス名を手動で処理する必要がなくなりました

  3. [〜＃〜] css [〜＃〜]内で[ 〜＃〜] jsx [〜＃〜]ファイル自体（私は長年その考えに反対していました）

  4. スタイル内でJavaScript変数を簡単に使用する機能

スタイル付きコンポーネント-短所

  1. 各スタイルコンポーネントはさらに別のラッパー関数であり、多くのスタイルコンポーネントはより多くの関数を意味します。つまり、コードを「コンパイル」する必要があるなどの理由で効率が低下します。
  2. 最大の欠点：スタイルの変更にはバンドルの再コンパイルが必要で、アプリの状態がリセットされる場合があります。

短所は、一部のシナリオではそのように表示できますが、必ずしもすべてではありません。

SCSS/LESS長所は上記の短所の反対と見なすことができますが、変数を扱う場合のミキシングや開発の高速化などの短所もあります（IMHO ）。ローカルセレクター変数を定義する「ugい」ものを取得できます。

これらの簡略化された例を比較します。

SCSSの例：

.icon{
  $size: '20px';
  width: $size;
  height: $size;
  margin-left: $size/2;
}

Styled-Componentsローカルスコープの例：

const Icon = styled.i(props => {
  const size = 20; // easier to use Number instead of String for calculations 
  return `
    width: ${size}px;
    height: ${size}px;
    margin-left: ${size/2}px;
`});

明らかに、変数はIconスタイルラッパーの外部で定義してから内部的に使用できますが、スタイルコンポーネントのCSSはスタイル付きのサブコンポーネントで構成され、CSSのように見えるため、分離されません。 ：

const Header = styled.header`
   > ul{
     ...
   }

   li{
     ...
   }

   img{...}

   navigation{...}
`

個々のHTML要素ごとに独自のstyledコンポーネントを抽出することが常に望ましいとは限りません。ほとんどの場合、アプリケーション全体で繰り返される、または繰り返される可能性のあるコンポーネントに対して行われます。

SASSミキシングに関しては、JavaScript関数に変換できるため、SASSにはあまり利点がありません。

全体的に、Styled-Componentsの操作は楽しくて簡単ですが、スタイルとフレームワーク/コンポーネント間のより緊密なカップリングの副作用があり、明らかにパフォーマンスの低下があります（実際に速度が低下することはありませんが、それでも） 。

0
vsync