さまざまなコンテキスト用にWebコンポーネントを作成します

この記事は、Webコンポーネントの構築方法に関するものではなく、最近Caleb Williamsが詳細なガイドを作成しました。それらの使用方法、構築する際にどのような要因を考慮する必要があるか、およびプロジェクトでそれらを効果的に利用する方法について説明しましょう。

Webコンポーネントを初めて使用する場合、Caleb's Guideは読む価値がありますが、すぐに開始するのに役立つリソースをいくつか紹介します。

• Webコンポーネント - 「正しい」アプローチ
• Shadow Dom V1：自己完結型のWebコンポーネント
• MDNのWebコンポーネント
• 素晴らしいWebコンポーネント
• 推奨されるオープンWebコンポーネント

Webコンポーネントが広くサポートされており（舞台裏の多くのハードワークのおかげで）、エッジがまもなくクロムプラットフォームに切り替わることを考慮して、人々は現在、Webコンポーネントを「ネイティブ」でプラットフォーム互換のUIコンポーネントと見なし、設計システムとWebプロジェクト間の一貫性を維持しながら、シャドードームのパンを覆い、コンポーネントをカプセル化します。

これは正しいことも間違っています。しかし、最初に、抽象的なレイヤーの三角形を見てみましょう。

抽象レイヤーの三角形

技術的には、Webコンポーネントをお気に入りのマークアップ言語HTML（はい！）の拡張と見なす必要があります。 WebコンポーネントAPIを使用すると、HTMLには存在しないカスタムHTML要素を作成できます（たとえば<foo-bar></foo-bar>）。

Webコンポーネントは基本的に新しいHTML要素であると言う人もいるので、それらをHTML仕様の一部として考慮する必要があるため、そのパラダイム、コア概念、および使用法に従う必要があります。これらすべてのポイントを想定すると、コンポーネントは、HTML、CSS、およびJavaScriptと並んで、Webプラットフォームスタックの最低レベルで存在することがわかります。フレームワークとライブラリ（React、Vue、Angular、Sveltejsなど）は、抽象化層で動作し、ステンシルジ、ハイブリッド、点灯などの「中つ国」のある種のツールの上に座ります。これらの抽象化レイヤーの下で、基本的なWebテクノロジーとネイティブWebコンポーネントを見つけることができます。この概念を表すために、 alt （抽象化la ayer t rianger）図を使用できます。

なぜこれが重要なのですか？ネイティブコンポーネントの上に存在するレイヤーを視覚化し、それらの使用環境を理解して、意図した環境に対して構築できるようにするのに役立ちます。環境は何ですか？それが私たちの目標です。

同じ技術、異なる環境

Shadow Domは、WebコンポーネントAPIの重要な要素です。これにより、JavaScriptとCSSをカスタム要素にバンドルして、明示的に許可しない限り、外部の干渉とスタイルの操作を防ぐことができます。開発者は実際に、モニカ・ディンクレスクが良い紹介をしている:: partおよび:: theme pseudo-elementsだけでなく、カスタムプロパティやテーマの概要など、外部CSSがシャドウルートとコンポーネントに漏れることを許可する方法に従うことができます。

考慮すべきもう1つのことは、私たちが使用している環境です。個人的にWebコンポーネントを構築してから3年後、2つの環境を特定できます：プライベート環境（設計システムなど）と標準環境（カスタムスタイルなしのプレーンHTML、CSS、JavaScriptなど）。

コンポーネントを設計する前に、それらがどのように使用されるかを理解する必要があるため、環境タイプを決定することがこのすべての鍵です。最も簡単な方法は、1つの環境のみをターゲットにすることですが、小さなCSSトリックを使用すると、両方のコンポーネントを構築できます。

深く掘り下げる前に、2つの環境の違いを見てみましょう。

プライベート環境

プライベート環境は、コンポーネントを独自のスタイルを提供する閉鎖エコシステムであり、そのまま使用する必要があります。したがって、特定のスタイルガイドまたは設計システムからコンポーネントのライブラリを構築している場合、各コンポーネントはカスタムスタイルを反映しているため、必要なときにエンコードする必要はありません。

JavaScriptロジックにも同じことが言えます。たとえば、閉じた影の根を取り付けて、他の人がQuerySelectorで影の境界を誤って貫通するのを防ぐことができます。したがって、任意のコンポーネントを選択して使用して、スタイルの矛盾やCSS競合などの問題を回避できます。著者として、特定のユースケースのコンポーネントのスタイルを使用するために使用できるCSSカスタムプロパティ（または::パーツ）のセットを定義することもできますが、これはシステムを設計することではありません。

これは、プライベート環境でWebコンポーネントを使用する例です。そのすべてのスタイルとロジックは、そのShadow-Rootに含まれており、任意のページに単純に追加できます。

この例とその後の例は、デモンストレーションのみを目的としており、アクセシビリティやその他の最適化などの重要な状況を考慮していないため、生産環境向けではありません。

プライベート環境のコンポーネントは、その環境以外ではめったに使用されません。たとえば、（独自の強制スタイルを使用して）設計システムから要素を取得しようとすると、プロジェクトに追加してカスタマイズすることを期待することはできません。 Bootstrapがあなたの好みに応じてテーマをセットアップしてカスタマイズする方法を知っていますか？これは正反対です。これらのコンポーネントは、環境で、そして環境でのみ実行することを目的としています。

標準環境

標準環境はおそらく最も複雑なコンポーネントタイプです。これは、環境がVUEなどの成熟したフレームワークから、プレーンネイティブHTMLに反応する可能性があるだけでなく、誰もがそのコンポーネントを他の要素であるかのように使用できるはずです。

たとえば、コンポーネントが公開されている場合（NPMに追加するなど）、それを使用する人は、少なくともある程度カスタマイズできると予想されます。

独自のデモスタイルのHTML要素を知っていますか？要素はCSSを明示的に使用する必要があるため、答えは「いいえ」でなければなりません。標準環境で作成されたWebコンポーネントにも同じことが言えます。単一のWebコンポーネントは、クラスとプロパティ、またはその他の方法を追加してカスタマイズできる必要があります。

これは、閉じた環境の例で見られるものと同じです<todo-list></todo-list>要素ですが、標準環境向けに設計されています。シャドウルートにデモスタイルはありません。実際、その機能を確保するために必要なロジックと基本的なCSSのみが含まれています。それ以外の場合は、標準のHTML要素（divなど）のようにカスタマイズできます。

各環境で表示される2つの例は、同じコンポーネントを使用して作成されました。違いは、標準環境のコンポーネントを外部CSSを使用してカスタマイズおよび選択できることです。

Webコンポーネントと構成

OK、したがって、Webコンポーネントを使用することは、実際にはプレーンHTMLを使用することと同じですが、私たちが見ることができるように、特定のコンテンツのパラダイムと原則に従うことは非常に重要です。注意する必要があるのは、Webコンポーネントの組み合わせです。

Google Webファンダメンタルズが説明するように：

組み合わせは、Shadow Domの最も知られていない機能の1つですが、間違いなく最も重要な機能です。

Web開発の世界では、構成はHTMLを使用して宣言的にアプリケーションを構築する方法です。異なるビルディングブロック（<div> 、<code><s></s> 、<em></em> 、<strong></strong> ）まとめてアプリケーションを形成します。これらのタグの一部は、互いに使用することさえできます。組み合わせが理由です<select></select>、<details></details> 、<summary></summary>そして<video></video>そのようなネイティブ要素が非常に柔軟である理由。各タグは、特定のHTMLを子要素として受け入れ、それらに対していくつかの特別な手術を実行します。例えば、<select></select>方法を知っています<option></option>そして<optgroup></optgroup>ドロップダウンリストとマルチセレクトウィジェットとしてレンダリングされます。<details></details>要素はそうします<summary></summary>拡張可能な矢印として提示されます。平<video></video>また、特定の子供の要素に対処する方法を知っています。<track></track>要素はレンダリングされませんが、ビデオの動作に影響します。なんて素晴らしい！構成は、HTMLを使用するときに通常行うことです。 Webコンポーネントは、DOM参照（論理コンテナではなく）を備えたHTML要素にすぎないため、コンビネーションとサブコンポーネントを構築するために組み合わせに依存する必要があります。あなたが考慮するなら

そして<select></select>、これらの要素を宣言的に組み合わせて最終出力を取得することに気付き、メインコンポーネント（ [readonly]など）または子コンポーネント（ [selected]など）に使用できる特定のプロパティがあります。 Webコンポーネントにも同じことが言えます。カスタムリストを作成する場合は、メインコンポーネントの構築を検討してください。<custom-list></custom-list> ）およびサブコンポーネント（<custom-li></custom-li> ）。使用<slot></slot>要素では、子要素が配置される場所と、子要素が渡されないときに表示されるプレースホルダーコンテンツを定義できます。

Webコンポーネントとアクセシビリティ

考慮すべきもう1つのことは、アクセシビリティの「小さな」テーマと呼ばれるものです。まったく新しいHTML要素を作成しているため、基本的なセマンティックロール、キーボードナビゲーション、およびモーションの削減やコントラスト設定の高さなどのユーザーのオペレーティングシステムの設定を提供するために、要素のアクセシビリティを考慮する必要があります。

アクセス可能で包括的なコンポーネントを構築するための参照、セマンティックタグの定義方法、および基本的なキーボードナビゲーションを実装する方法として、次のリソースを強くお勧めします。

• 包括的コンポーネント
• web.devの「すべての人に効果」
• ワイアリアクリエイティブプラクティス
• webaim wcagチェックリスト

結論は

WebコンポーネントはWeb開発における新たなテクノロジーであるため、目的の使用または最大化に基づいてそれらを構築することに関して、明確に定義されたベストプラクティスはありません。あなたがそれらを使用していることに気付いたとき、あなたがこの投稿から得るかもしれない唯一のことは、それらが閉じた環境であるか標準環境であるかを検討し、自問することです。

• Whoはこのコンポーネントを使用しますか？
• この人はそれをカスタマイズする必要があるはずですか？
• このコンポーネントは、すべての人に適していますか、それとも特定の視聴者に適していますか？