Webコンポーネントライブラリで少し

最近、Webコンポーネントに関する多くのニュースがありましたが、ここで整理します。

Webコンポーネントに最適なアプリケーションシナリオの1つは、パターンライブラリだと思います。ブートストラップのように使用する代わりに<div>、またはそれをbulmaのように使用します<code><div>、カスタム要素を使用する方が良いです。<code><designsystem-tabs></designsystem-tabs> 。新しいShoelaceライブラリは、 slネームスペースを使用してコンポーネントを定義しています。これは、タグがあるWebコンポーネントに完全に基づいたスキーマライブラリです。<sl-tab-group></sl-tab-group>要素。

これを行うことの利点は何ですか？まず、コンポーネントモデルを導入します。これは、コンポーネントで作業している場合、その場所に関連するテンプレートとスタイルシートがあることを意味します。 Shoelaceの内部実装を見ると、すべてがステンシルに基づいていることがわかります。

もう1つの利点は、コンポーネントがShadow Domを使用（および使用する）ことができることです。これにより、Webプラットフォームから直接分離メカニズムが提供されます。 CSS開発者にとって、これは、タグコンポーネントのタグのスタイルが.tabクラスを使用して実行されることを意味します（すごい、とてもクールです！）が、そのコンポーネントで分離されています。このような一般的な名前でさえ、私はページ上の一般的なクラスの他のコンポーネントに誤って影響しませんし、ここで内部構造を妨害する外部CSSもありません。 Shadow Domは、スタイルが漏れや浸透を防ぐセキュリティウォールのようなものです。

また、コンポーネントのセットでもある高速フレームワーク¹も表示されます。そのタグは次のように定義されています<fast-tabs></fast-tabs>。これは、スキーマライブラリ方法としてのWebコンポーネントの別の利点を思い出させます。コンポーネント自体の名前から始めても、API駆動型のように感じます。これは実際にHTMLで使用しているものです。この要素のプロパティは完全にカスタマイズできます。新たな標準は、カスタムプロパティにdata-プレフィックスを追加する必要さえないようです。だから私がタグコンポーネントを作りたいなら、それは<chris-tabs active-tab="lunch" variation="rounded"></chris-tabs>。

おそらく、スキーマライブラリとしてWebコンポーネントを使用している最大のプレーヤーはIonicです。彼らのラベルはそうです<ion-tabs></ion-tabs>、他のフレームワークを伴わずに使用できます（ただし、独自のステンシルに加えて、Angular、React、およびVueをサポートします）。 IonicはWebコンポーネントで大きな進歩を遂げ、最近Shadow Partsをサポートしています。これは、パッケージを再び説明するブランディカーニーの説明です：

Shadow Domは、スタイルがコンポーネントから漏れ、他の要素に誤って適用されるのを防ぐのに役立ちます。たとえば、 .buttonclassを割り当てます<ion-button></ion-button>コンポーネント。 Ionic Frameworkユーザーが独自の要素の1つに.buttonクラスを設定すると、フレームワークの以前のバージョンでは、イオンボタンスタイルを継承します。なぜなら<ion-button></ion-button>現在、シャドウウェブコンポーネントなので、この問題は存在しなくなりました。

ただし、このカプセル化により、スタイルはシャドウコンポーネントの内部要素に侵入することはできません。これは、シャドウコンポーネントがシャドウツリーに要素をレンダリングする場合、ユーザーはCSSを使用して内部要素を見つけることができないことを意味します。

カプセル化は良いことですが、スタイリングを「慎重に」（意図的に）します。理解すべき重要なCSSの概念があります。CSSカスタムプロパティは、シャドウDOMに浸透する可能性があります。しかし、人々がデザインシステムのすべてを「さまざまに」することを決定することは賢明ではありません。代わりに、Shadow Dom内の各HTMLフラグメントにパーツを与えます。<div part="icon"> 、CSSを使用して「外部からアクセス」することができます。 <code>custom-component::part(icon) { } 。パーツベースのスタイルフックはほとんどが良いと思いますが、このようなパターンライブラリの賢明なソリューションですが、その一部が私を悩ませていることを認めています。セレクターは、予想とは異なる方法で動作します。たとえば、コンテンツを条件付きで選択することはできません。子要素を選択したり、カスケードを使用したりすることもできません。言い換えれば、それはただ一回限りであるか、あなたがあなたの手で映画をまっすぐに通っているようなものです。あなたは前進して何かをつかむことができますが、何もできません。

人々を怒らせることについて言えば、アンドレア・ジャンマルチは、ウェブコンポーネントの現在の状況について良い視点を持っています。

私のものを含む始まったすべてのライブラリは、「ポータブルカスタム要素」と呼ばれるものを定義するためにライブラリをインポートする必要があることを示唆しています。

Googleは常にLitelementの使用をお勧めします。 Microsoftは、ファスターレメントを使用してほしいと思っています。ステンシルには独自のコンポーネントがあります。 HyperHTMLには独自のコンポーネントがあります。 「生の」Webコンポーネントのみを使用する人はいません。これはとても奇妙です！最悪の部分は、Webコンポーネントが「ネイティブプラットフォーム」のものである必要があるということです。つまり、特定のテクノロジーに頼る必要はないはずです。これを行うと、Reactなどを使用するようにロックされています。

Andreaは、いくつかの新しいライブラリを使用するなど、いくつかのアイデアを記事に掲載しています。私が見たいのは、ライブラリをまったく使用しないスキーマライブラリだと思います。

1. Fastは、ホームページの連続文の「インターフェイスシステム」と呼ばれ、その後に「UIフレームワーク」が続きます。靴ひもはそれ自体を「ライブラリ」と呼んでいますが、「モードライブラリ」と呼んでいます。 「設計システム」は、この概念を説明するために最も一般的に使用される用語であると思いますが、多くの場合、特定の技術よりも広範囲です。 Fastは、この用語をコード自体で使用して、主題を制御するラッパー要素を示します。このすべてを取り巻く用語は、確かではないとは思いません。