この投稿は、 Twitterでのこの会話からの質問に対する詳細な回答です。 オリジナルの作者であるSunil Pyeは、比較的人気のあるグラマーライブラリの作者であり、Facebookで開発者として働いています。
JavascriptはCSSよりもどのように便利ですか？ JS内にCSSを記述すると、どのようにサポートされるようになりますか？
このトピックについてお話させていただきます。 CSS-in-JSソリューションにはオーバーヘッドがあるとすぐに言わなければなりませんが、通常、この価格はそれらがもたらす利点によって正当化されます。 時には役立つ場合もありますが、これはCSS-in-JSを常にどこでも使用する必要があるという意味ではありません。
そのため、CSS-in-JS（cij）で最も重要なことはCSSセレクターです。 cijの最大の利点は、コンピューターがこれらのセレクターを自動的に生成できることです。 OOCSSなどの規則 原則として、これらは優れていますが、共通の名前空間で一意性を確保するのが難しい手書きセレクタに基づいています。これは、常に交差する可能性があるためです。 今それが起こらなければ、チームが成長し、状況が変わる3年後に起こる可能性があります。 この状況は、サードパーティのライブラリを使用すると悪化します。 CSSセレクターのスコープを制限することも、この機会にぴったりのCSSモジュールを使用して実現できます 。
それでも、これらのすべてのアプローチでは、セレクターを静的に分析し、壊れている（またはタイプミスを含む）セレクターを見つけることは非常に困難です。つまり、セレクターはコードレビュープロセスで手動でチェックする必要があり、コマンドの有効性が低下します。 私たちはコンピューターの助けを借りなければならず、人々の完全性と無欠さに頼らないでください（そうではないからです）。 CSS-in-JSを使用すると、一意のセレクターと識別子の生成を自動化できます。
さらに、CSSセレクターの強化された制御は、以前は簡単にアクセスできなかった新しい可能性を開きます。 たとえば、HTMLブロックと必要なスタイルを一致させることで、重要なCSS抽出を簡単に実装できます。これにより、ページの初期表示に必要な1〜2 KBのCSSのみをページにロードできます。 ランタイムなし！ GatsbyやNextなどのフレームワークは、これを積極的に使用して、それらに基づくプロジェクトのパフォーマンスインジケーターを改善します。 ダウンロード可能なHTMLに重要なCSSを直接埋め込むのは、ページの読み込みをブロックする追加のリクエストよりも優れているというだけの重さがあるからです。 これにより、初期ページのレンダリング時間が大幅に短縮されます。 さらに、ロードされたJavaScriptのサイズの問題を解決するのにも役立ちます！ 利点は、重要なCSSを適用すること、動的import()
使用すること、 コード分割 、未使用コードの削除から得られます。 （開発者が既存のコードに触れることを恐れて、新しいコードを追加するだけのレガシスタイルファイルとは対照的に、 このトピックに関する分析が少しあります 。）
テーマの実装に関する同様の状況。 CSS変数は、非常に興味深いものであっても、元々意図されていたユースケースに移行しなかったこと、そしてすべて古いブラウザーのフォールバックメソッドが非常に複雑または劣っていたためです。 つまり、通常はグローバル定数として使用されますが、ブラウザーで値が動的に決定される変数として使用されることはほとんどありません。 CSS CSSランタイムを使用すると、JSからスタイルに値を渡すことができ、これが可能になります。
実際、それを気に入るはずです。 すべてのブラウザーでCSS変数を最終的に正直に使用できます。つまり、CSS変数をサポートするブラウザーのランタイムなしのネイティブ機能、および古いブラウザーの特別なランタイムです。 （ ここでこれについて詳しく説明しました-正しく理解できれば-これがこれを達成した唯一のライブラリです）。
多数のコンポーネントと、スクリプトやスタイルなどのリソースの非同期ロードを伴う複雑なSPAの状況では、スタイルのロードの正確な順序を保証できないため、スタイルの順序を保証するために何らかのランタイムソリューションを作成するか、単に使用する必要があります!important
何らかのCSS方法論に固執する場合 。 たとえば、 class=“ab”
要素がありますが、クラスa
とb
異なるスタイルファイルで定義されているため、スタイルファイルの順序が明確でない場合、ブロックの最終形式を確認できません。 Facebookコードベースには、 !important
何千もの使用が含まれていますが、コードは、SOLID原則と設計チームとの良好な相互作用を使用して、資格のあるプログラマーによって作成されました。
これは、CSSをJavascriptであるかのように扱うことを指すことがよくあります-10年前に既にJSについて同様の問題を解決していたことを考えると、ライブラリおよびモジュールはグローバル名前空間（ $
など）に登録されていたため、接続順序に十分注意する必要がありましたHTMLのスクリプト。 しかし、私たちは永遠にそこにとどまりませんでした-現在、私たちはモジュールを使用しており、アセンブリシステムはそれらを保証された正しい順序で縫い合わせています。 これは私たちにとってシンプルで透過的です。
実際のプロジェクトを見ながら、CSS-in-JSの世界では従来のアーキテクチャのアプローチ（OOCSSやSMACSSなど）を引き続き使用できることに気付きました-これらのアーキテクチャの要素は、+セレクターブロックではなく、JSオブジェクトによって表されますスタイル。 私はこのアプローチを採用し、私にとってはうまく機能しています。 ここで詳細を読むことができます。
CSS-in-JSの欠点もよく知っています。 実際、これがまさにCSS-in-JSを表す「標準」ライブラリが存在しない理由です。バニラの静的CSSからスタイル付きコンポーネントのような完全に動的なライブラリまで、さまざまなソリューションのスペクトルです。 SASSやLESSなどのプリプロセッサは、著者の裁量でこれらのライブラリのいずれかで理論的に使用できるため、このスペクトルに対して垂直に見える場合があります。 これらのライブラリにはそれぞれ欠点があります-実行時に費用がかからないようにアセンブリ段階でスタイルを抽出するもの、開発者の正確性や利便性に焦点を合わせるもの、複雑なアニメーションの効果的な実装に焦点を合わせるものなどがあります。 この多様性は、急速に成長している業界で、さまざまな作業タスクのためのさまざまなソリューションの必要性に対する自然な反応です。 そして、これはライブラリだけでなく、Web標準の開発者（ShadowDOMなど）もこれらの問題を積極的に解決しようとしていますが、その解決策にも欠点があります。少なくとも、どこでも利用できないため、使用できません。多くのチームで。
私はこれについて強い感情を抱いていましたが、過去数か月にわたって自分の意見を緩和しました。 真実は実際には真ん中のどこかにあることがわかります-それはチーム、要件、時間、ドキュメント、および他の多くの要因に依存します。 さらに、このテキストがこのアイデアの「最終形態」を表すとは思わない。 この分野での実験を奨励して、他にもっとできることを見つけ出し、これらのいくつかをブラウザーに組み込むこともできます。
PS遅すぎるので、「翻訳」ボックスをチェックするのを忘れたことに気づいたので、このように公開されました。 オリジナルへのリンク 。
Habr、インターフェイスを修正しました。公開後に翻訳フラグを追加できないのはなぜですか？