最近、私は有名なポッドキャストを聞いていましたが、素晴らしいホストが Web コンポーネントについて話し、さまざまな Web コンポーネントの仕様と機能について良い点、悪い点、悪い点をすべてリストアップしていました。
まったく公平なエピソードと素晴らしい会話について、クリス・コイアーとデイブ・ルパートに感謝の意を表します。ここでエピソードを聞いてください:
ショップトークショー
とにかく、あのエピソードの奥深くで、CSS パーツが悪者リストにランクインしていることを知って驚きましたが、人々が CSS パーツが最高ではないと考える理由のいくつかは理解できました。私はたまたま、CSS パーツが非常に優れているだけでなく、実際に CSS パーツを使用する私たち全員を、Web コンポーネントのシャドウ ルート内のすべての要素をまったく同じようにスタイル設定できないことよりもはるかに煩わしくイライラするシナリオから救ってくれていると考えています。
説明しましょう。その前に、詳しい内容を説明します。
以下のすべてが真実であることを明示的に検証することはできませんが、過去数年間、本業で Web コンポーネントの機能の仕様を作成、使用、支援する中で得た私の個人的な意見は、既存の Web コンポーネントの仕様と機能は次のとおりです。これらはすべて、「サードパーティ コンポーネント」の使用例を解決するように設計されています。つまり、Web コンポーネントは、非常に特殊な状況をサポートするように設計されています。コンポーネント作成者が、他の消費者がインターネットからダウンロードしてアプリで使用するツールを作成します。
Web コンポーネントの機能を「サードパーティ コンポーネント」のユースケースというレンズを通して見ると、仕様作成者やブラウザ実装者が採用したアプローチの多くは非常に理にかなっていると感じます。たとえば、Shadow dom スタイルのカプセル化の重大度を考えてみましょう。コンポーネントをインターネットから取得してアプリに取り込む場合、そのコンポーネントの CSS が何らかの理由でページの 1 つを破損するのではないかと心配する必要がないのは素晴らしいことではないでしょうか。自分が書いていないコンポーネントの内部構造を気にする必要がなく、そのコンポーネントをブラック ボックスのように扱い、明確に定義された API サーフェスを通じて対話できるのは素晴らしいことではないでしょうか?
Web コンポーネントがどのように動作するように設計されているかを理解する際に最も問題となるのは、Web コンポーネントの仕様が作成されて以来業界が進歩しており、最近ではアプリで使用するコンポーネントの 99% が外部ソースから来ていないことです。 。最近、コンポーネントについて考えるとき、ほとんどの場合、インターネット上の誰かが作成したものではなく、私たちまたは私たちのチームが作成した「ファーストパーティ コンポーネント」について考えています。私たちはアプリケーションでそれほど多くの外部コンポーネントを使用しないため、主にそのユースケース向けに設計された Web コンポーネント API は、特に Web コンポーネントを使用して自分用のファーストパーティ コンポーネントを作成しようとする場合、奇妙に思えます。
したがって、この記事で私が述べる他のすべてのことについては、「サードパーティ コンポーネント」の状況について言及していると仮定してください。私が話しているコンポーネントは、あなたがダウンロードした npm パッケージであり、GitHub の Readme やパッチノートなどは存在しますが、あなた (またはあなたのチーム) が自分のアプリ用にそれを自分で書いたわけではないと想像してください。
CSS パーツは、自分自身またはチームのために作成し、完全に制御できるコンポーネントをスタイリングするための優れたインターフェイスではありません。
適切に設計されたコンポーネントには、それらと対話するためのいくつかの異なる方法があります。優れた Web コンポーネントには、カスタマイズされた HTML 用のスロット、カスタマイズされたテーマ用の CSS カスタム プロパティ、およびカスタマイズされたスタイル用の CSS パーツがあります。ショップ トーク ショーのメンバーは、CSS パーツがフリー フォーム スタイルには不格好であるという文脈で CSS パーツについて議論しましたが、私は CSS パーツについてそのようには考えません。私はこれらを、属性やプロパティと同じように、コンポーネントの別のパブリック API サーフェスとして考えると思います。通常、インターネットから取得したコンポーネントのカスタム プロパティや属性を作成できないことについては、あまり心配しません。 CSSパーツも同じ考え方だと思います。コンポーネントの作成者は、任意の方法で「スタイルを適用できる」内部テンプレートの部分を指定します。したがって、Shadow dom Web コンポーネント内のすべての内部要素をスタイルできることは、必ずしも期待されるべきではありません。
そして、複雑なテンプレートのどの部分にスタイルを適用しても問題ないかをコンポーネントの作成者以上に知っている人はいないでしょうか。すべてのスタイルを方向転換して書き直すためだけにインターネットからコンポーネントを取り込み、その過程でアクセシビリティなどが破壊される可能性がある場合、そもそもなぜそのコンポーネントをインストールしたのでしょうか?多くの人が提唱しているシャドウ ルートの「自分が何をしているのかわかっている」セレクターの魅力はわかりますが、この次のセクションでは、次のような定義されたスタイル API サーフェスを持つことがなぜ私が考えるのかを説明します。内部 DOM 構造から切り離されたことは実際に驚くべきことであり、私たち開発者全員が混乱しないように支援したことを称賛されるべきです。
昔ながらの映画の予告編の音声をキューに入れます
CSS パーツが存在せず、「自分が何をしているのかわかっている」セレクター (懐かしさのために /deep/ と呼びましょう) が存在し、それが「方法」である架空の世界に飛び込んでみましょう。シャドウ ルート Web コンポーネントの内部 DOM テンプレートのスタイルを設定する必要があります。
アプリにはそのようなコンポーネントが 1 つ必要なので、npm パッケージをダウンロードします
npm i some-awesome-package@1.2.3
アプリケーションに次の HTML を含めます:
<some-awesome-component></some-awesome-component>
Some Awesome Component コンポーネントにはデフォルトで赤色の div があり、CSS カスタム プロパティを使用しません。そして最初は、red div はまったく問題ありません!
しかし、その後、赤の div の色を rebeccapurple に変更する必要があると判断しました。したがって、次の CSS を書きます:
@layer my-overides {
some-awesome-component /deep/ div.the-red-div {
background: rebeccapurple;
}
}
the-red-div はクラスとしてはひどい名前ですが、Shadow dom Web コンポーネントの内部構造など誰も気にしませんよね?これらは外部の世界と競合できないため、コンポーネント作成者は必要に応じてひどいクラス名を作成できます。
そして、私たちは /deep/ が存在する想像の世界にいるので、すべてがうまくいきます!赤の div が紫になり、すべてが Coolio になります。
あなたは、.the-red-div の色が赤ではないという私たちの脳内の小さな認知的不協和を無視しています。それは明日の問題です。
素敵です!
その後、コンポーネント作成者は機能を追加し、パッチ バンプを公開します。
あなたは発送で忙しく、その途中で無関係なパッケージを再インストールし、Some Awesome Component の最新のパッチ バンプをプルしたところ、赤い div が再び戻ってきました。
何が与えますか?パッチノートを検索すると、次のことがわかります。
## 1.2.4 - [a987s83] Added cool button, fixed a11y issues
問題ないようですが、CSS が壊れたのはなぜですか?変更ログのメモには手がかりがありません。つまり、最新のいくつかの PR をざっと読んでも、目に留まるものは何もありません。
そこで、アプリケーションを起動してシャドウ ルートを確認すると、赤い div が になっています。今！そして、コンポーネントの作成者は、the-red-div のクラス名がもっと一般的であるべきだったことに気づき、それをカラフルな名前に変更しました。
わかりました。CSS を次のように編集します。
@layer my-overides {
some-awesome-component /deep/ .colorful {
background: rebeccapurple;
}
}
そしてまた正常に動作します!
その後、作者は来週別のパッチ バンプをリリースします。
現実世界にジャンプカットバック
パターンを見て、所有または制御していない内部テンプレートへの直接セレクター アクセスに問題があることを確認してください。
必然的に、コンポーネントの利用者であるあなたの制御の範囲外で内部テンプレートに変更が加えられます。そして必然的に、これらの変更は、手動または不安定な視覚的回帰テスト ツールを使用して、実行中のアプリのすべての部分を視覚的に検査しない限り、ほとんど目に見えない形で発生します。インターネットからのコンポーネントを使用している場合は、一種の契約が必要です。コンポーネントの作成者は Shadow dom を所有し、利用者は :host 要素 (作成したコード内の
面白いことに、この脆弱性は、JS で DOM 要素に対して直接シャドウ dom querySelectors を実行するときにも発生します。アプリが常に存在するために何らかの要素に依存している場合、その要素は存在しません。自分が制御していない DOM にクエリを実行すると、いつか要素が存在しなくなります。それは別の要素であるか、別のクラス/属性/ID を持つことになります。
CSS パーツは DOM 要素自体ではない単純な文字列であるため、CSS パーツを使用するとアプリケーションが脆弱なコードから保護されます。サードパーティの作成者は、ある div が常に永遠に div であるかどうかをテストするつもりはありません。しかし、CSS パーツを作成する場合、破壊的な変更を行わなければ削除または変更できないコンポーネントのパブリック API を作成していることがわかります。また、Shadow DOM を直接クエリする代わりに CSS パーツを使用すると、コンポーネント作成者はその CSS パーツを Shadow DOM 内で移動でき、アプリケーション コードは壊れません。
さらに、CSS パーツ名は関係、概念、機能を暗示するため、コンポーネント作成者が CSS パーツの意味を大幅に変更するような方法でコンポーネントをリファクタリングすることは困難です。そのため、コンポーネントの作成者が何も言わずに変更を加えても、コードを使用している CSS パーツが壊れることはないということを知ることに加えて、CSS パーツが全体との関係において常に同じ種類のものであることを合理的に確信することもできます。成分。そのため、コンポーネントが時間の経過とともに進化しても、そのパーツに適用するスタイルは、そのパーツにとって常に「意味をなす」ものであることがかなり確実になります。
非常に聡明で貴重な業界関係者から、CSS パーツの苦痛について、またセレクターを介して直接 Shadow DOM アクセスを追加した方がはるかに便利であるというコメントをいくつか見てきました。時間が経っても何も変わらないとしても、私は心から同意するでしょう。しかし、コンポーネントは時間の経過とともに変化するため、どの CSS パーツが使用可能かを覚えておくよりも、直接 Shadow DOM にアクセスする方が面倒だと思います。
「アプリ」とコンポーネント内のシャドウ ダムの間の境界を越える方法について議論があるときは常に、私は直接セレクター アクセスではなく、CSS パーツのような名前付きの構造的契約アプローチを常に支持します。私の考えでは、CSS パーツがかっこ悪くてひどいと思う人は、アプリ全体を調べて、知らないうちにシャドウ ルート テンプレートが変更されているすべての場所を探す必要がなかっただけです :)
CSS パーツは素晴らしいものであり、それを使用すると、たとえあなたが 100% 優れた開発者であり、自分が何をしているのかを理解しているとしても、カスタム CSS をすべて微調整しなければならない可能性があるという苦痛も 100% 望んでいません。使用するコンポーネントにパッチが適用されるたびに、そのように書きます。あなたは自分が何をしているのか確かに知っていますが、私たちは皆、アプリがランダムに壊れるのを防ぎたいと考えており、それが直接シャドウ DOM スタイル設定によって行われます。 「何をしているのか分かっている」セレクターは間違いなくスタイリングを機能させますが、スタイルを設定したパッケージのバージョンを文字通りまったく更新しない場合にのみ機能することが保証されます。バージョンを更新する場合は、「自分が何をしているのかわかっている」スタイルすべてに毎回目を光らせる必要があります。
それは貴重な時間の無駄です。 CSS パーツを使用し、コンポーネント開発者が作成したコンポーネントに CSS パーツを追加するよう奨励してください。
以上がCSS パーツが悪夢からあなたを救いますの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
