独自のコンポーネント ライブラリを最初から構築する前に、世の中にあるさまざまな種類のコンポーネント ライブラリと、それらを使用する利点と欠点を見てみましょう。
?校正とフィードバックの提供については、stephband (Mastodon、Bluesky) に特別な感謝の意を表したいと思います。
これは私のサイトからの X-Post であることに注意してください。内容はほぼ同じですが、元の投稿にはインタラクティブなスニペットとビデオが含まれていますが、この記事では省略されています。
私は大の音楽ファンです。私のお気に入りの娯楽の 1 つは、レコードをかけて前から後ろまで聴くことです。音楽アルバムはコンセプトがシンプルで、アーティストによって録音された一連のトラックであり、完全で一貫した曲のセットとみなされます。
しかし、録音された音楽が存在しなかったらどうなるでしょうか?曲をテープ、CD、または MP3 (または FLAC) に保存する代わりに、アーティストがライブで演奏した場合にのみアルバムを聴くことができます。バンドのところに行き、機材をセットアップしてもらい、アルバムを最初から最後まで再生してもらう必要があります。全員がまったく同じ体験を確実にできるように、毎回同じ方法でプレイする必要があります。
亀裂が目立ち始めます。これは、バンドの音楽に興味のある人が確実にその音楽を聴けるようにするための効率的な方法ではありません。テイラー・スウィフトが、Spotify で聴いたすべての人に自分の曲『フォートナイト』を個人的に演奏したとしたら、3,179 年かかることになります。そして、これには飛行機での移動は含まれていません。アーティストは退屈し、場合によっては不注意になり、リスナーの体験の低下につながります。
では、これは Web 開発とどのように関係するのでしょうか? UI コントロールを構築するたびに、それが機能し、堅牢で、アクセスしやすいことを確認する必要があります。毎回同じUIを書き換え続けると飽きてしまいます。間違いが見逃され、エンド ユーザーのエクスペリエンスが悪化します。
私は 10 年近く Web 開発者として活動しており、何百ものコンポーネントを自分で作成してきましたが、その多くは同じ UI パターンを何度も作成しました。私は数十のコンポーネント ライブラリを使用し、管理ダッシュボード、コンポーネント ライブラリ、モバイル アプリケーション、ブログ、figma プラグイン、VSCode 拡張機能などを構築してきました。この記事は、コンポーネント、ライブラリの役割を私がどのように考えているのか、そして開発者が独自のライブラリを作成すべきかどうかについて抽出したものになります。
ユーザー インターフェイスを構築するとき、毎回すべての HTML マークアップを最初から作成するわけではありません。私たちは、一般的な UI パターンをカプセル化する再利用可能な構成要素であるコンポーネントを使用して UI を作成します。コンポーネントを作成すると、そのコンポーネントを 1 つのプロジェクト内、または独立したプロジェクト内で複数回使用できるようになります。
ここではカウンターコンポーネントを作成しました。一度書いて、ページ上の複数の場所で使用しました。
<body>
<div class="wrapper">
<counter-button></counter-button>
<counter-button></counter-button>
<counter-button></counter-button>
</div>
<script type="module">
import { LitElement, html } from 'lit';
class CounterButton extends LitElement {
constructor() {
super();
this.count = 0;
}
static properties = {
count: { type: Number }
};
_increment() {
this.count++;
}
render() {
return html`
<button @click=${this._increment}>Count: ${this.count}</button>
`;
}
}
customElements.define('counter-button', CounterButton);
</script>
</body>
私たちチュートリアル作成者は、時代遅れになったかのようなカウンターのデモをしたがりますが、実際のアプリケーションにはコンポーネントとして記述された数十の異なる UI パターンが含まれます。
この記事では、特定の UI パターンのスタイルを提供する CSS ルールをコンポーネントの傘下にグループ化します。誰に尋ねるかによっては、その定義があいまいになる可能性があります。
すべてのコンポーネントがスタンドアロンであるわけではありません。多くのコンポーネントをコンポーネント ライブラリと呼ばれる 1 つのパッケージ内にグループ化するのは理にかなっています。
サイトに特定の外観や雰囲気を持たせたい場合は、コンポーネント ライブラリを使用できます。次のコンポーネント ライブラリがあります:
しかし、形や大きさもさまざまです。コンポーネント ライブラリを定義するときに私が使用するようになった定義は次のとおりです:
コンポーネント ライブラリは、ユーティリティまたは外観 (あるいはその両方) がまとまった再利用可能なコンポーネントのセットです。優れたコンポーネント ライブラリは、開発者が UI のニーズを効率的に達成するのに役立ち、同時にエンド ユーザーに模範的なエクスペリエンスを提供します。
ガイドラインとデザイン システムについてはこの記事の後半で説明するので、少し時間をかけて曖昧さを解消します。一方がどこで終わり、一方が始まり、一方が他方を包含するのかを理解するのは難しい場合があります。
デザインシステム
私はデザインシステムを、物事がどのように見え、感じられ、動作するかについての仕様であると考えています。デザイン システムには製品、ブランド、または企業を含めることができ、一連のエクスペリエンス全体での一貫性を確保できます。包括的なデザイン システムにより、フォント ファミリー、フォント サイズ、間隔サイズ、UI パターン、コピー ガイドラインに至るすべてが決定されます。
最もよく知られているデザイン システムには次のようなものがあります。
多くのデザイン システムは企業に固有のものですが、マテリアル デザインのようなデザイン システムは、世界中のチームが使い慣れた感触の製品を構築する近道として使用しています。おそらくマテリアル デザインの原則を使用したいくつかの製品を使用したことがあるでしょうが、基本的なユーザビリティの問題がまったくないわけではありません。
コンポーネント ライブラリ
コンポーネント ライブラリに関しては、デザイン システムのコード実装である場合とそうでない場合があります。デザイン システムを導入している会社で働いている場合は、対応するコンポーネント ライブラリ (存在する場合) がそのシステムと緊密に統合されている可能性があります。
たとえば、Google のマテリアル Web は、マテリアル デザインの Web コンポーネント実装です。 Base Web コンポーネントと Lightning Web コンポーネントもオープンソースです。
UI コンポーネント (またはウィジェット) の概念は長い間存在しています。博物館に匹敵するほどのレトロなユーザー インターフェイスを見たい場合は、ポップコーンを手に取り、1974 年から 1990 年までの「すべてのウィジェット」をまとめた 2 時間以上のビデオをご覧ください。
2000 年代初頭から、開発者が Web 用に構築するのを支援するために作成されたコンポーネント ライブラリが見られるようになりました。当時の Web ブラウザの風景は、今私たちが見ているものからは認識できませんでした。 Internet Explorer のバージョンは仕様から完全に逸脱しており、当時 IE が巨大な市場シェアを持っていたことを考えると、これは特に問題でした。 Internet Explorer 6 は、開発が面倒であることで有名でした。主な原因は、ボックス モデルの実装が間違っていることと、CSS2 がサポートされていないことです。
?これまで、Internet Explorer は、標準をサポートしていない古いブラウザを緩和するために、開発者が非標準の HTML と CSS を記述できる「quirks モード」をサポートしていました。
幸いなことに、私が Web 開発を本格的に始めたとき、これらの問題の多くは解決されました。 この時点では、クロスブラウザーをサポートする複雑なインターフェイスの作成を少し簡単にするライブラリがまだいくつかありました。私が最初に使用したコンポーネント ライブラリである jQuery UI は、アコーディオンやその他のウィジェットをサポートしていました。しかし、ブラウザは常に進化しており、詳細要素と概要要素を使用してこのアコーディオン パターンを実装するネイティブな方法が 2020 年にはすべてのブラウザで利用できるようになりました。これらの要素を使用すると、JavaScript を使用せずにインタラクティブなアコーディオンを作成する作業をかなり進めることができます。
これを 2009 年と比較すると、これらの要素はどのブラウザにも実装されていません。動作させるにはかなりの量の JS が必要でした。 15 年前に Web 開発者がどのようにアコーディオンを実装していたのかを知りたい場合は、jQuery UI v1.7 のソース コードをご覧ください。
その後数十年にわたって、ウェブの機能は成長しました。より強力なデバイスはより強力なブラウザを意味します。ブラウザーが強力になると、Web アプリケーションもより野心的になりました。開発者は、ビルディング ブロック、つまりコンポーネント モデルを使用して UI を作成できるようにすることで、これらのアプリケーションの構築を支援するツールを作成することで対応しました。これらのコンポーネントベースのフレームワークの急増が見られました。私は Angular、React、Vue について話しています。それぞれにコンポーネント ライブラリの独自の豊富なエコシステムがあります。
過剰修正が行われ、フロントエンド環境がほとんどの人のニーズに対してあまりにも強力なツールで飽和状態になっているという合理的な議論がありますが、そこには立ち入りません。
このバージョンは、元の投稿にインタラクティブなスニペットが追加されて拡張されています
コンポーネント ライブラリを構築する際の課題は、一度行ったら終わりではないということです。最も人気のあるライブラリの多くは何年も前から存在しており、現在の状態に到達するまでに膨大な研究、使用に関するフィードバック、貢献が行われてきました。
優れたコンポーネント ライブラリには、次のような特徴があることがわかりました。
逆に、コンポーネント ライブラリが良くないかどうかを見分ける方法は、アクセシビリティを考慮していない、一貫性のない API がある、プロジェクト管理がほとんどない、またはまったく機能していない場合です。明確で一貫性のあるドキュメント。
私たちは優れたコンポーネント ライブラリがどのようなものかを知っています。それでは、どのようにしてあなたの生活とユーザーの生活をもう少し良くできるかを見てみましょう。
期限が厳しいプロジェクトに取り組んでいる場合は、効率的に作業することが重要です。しかし、堅牢な Web エクスペリエンスを構築することを犠牲にして効率性を実現するべきではありません。コンポーネント ライブラリを使用すると、車輪の再発明に費やす時間が減り、より細かい部分に集中できるようになります。
私たちは繰り返しの作業によってモチベーションが上がるわけではありません。私たちは技術的な挑戦を楽しんでいますが、同じコンポーネントを何度も書くことは楽しい挑戦ではありません。退屈して間違いを見逃してしまうと何が起こるかについてはすでに話しました。
ダイアログ コンポーネントを最初から実装したい場合は、次のことを行う必要があります。
上記のことを覚えて実装するには手間がかかりますが、間違った方法でフォーカスを処理した場合など、インターフェイスが文字通り使用できなくなる可能性があります。
エンド ユーザーを念頭に置いて構築されたコンポーネント ライブラリを使用すると、同じコンポーネントの再構築にかかる時間を短縮しながら、壊れたエクスペリエンスが発生するリスクを防ぐことができます。
複数の異なる Web アプリケーションを使用する会社で働いている場合、その会社は通常、一連のガイドラインに従います。これらのガイドラインは、使用するカラー パレット、タイポグラフィのサイズ、UI 要素の外観と動作を決定する場合があります。
しかし、コンポーネントを書き直すと、アプリケーションがスタイルガイドから逸脱する可能性が高くなります。コンポーネント ライブラリを用意すると、ブランド ガイドラインに照らしてコンポーネントの UI をより簡単に監査できるため、どこで使用しても見栄えが良くなります。
Uber には、同じユーザー インターフェース要素を共有するいくつかの異なるアプリがあります。これらのアプリ間で同じコンポーネント ライブラリが使用されているとほぼ確信しています。そうすることで、各新しいアプリがブランドのガイドラインに準拠していることが事実上保証されます。
上で述べた利点は、独自のコンポーネント ライブラリを使用しているかサードパーティを使用しているかに関係ありません。あなたまたはあなたのチームがライブラリを構築せず、代わりにサードパーティに依存すると決めた場合は、次のことを検討する価値があります。
コンポーネント ライブラリを選択することにより、フロントエンド コードの記述方法とインターフェイスの外観と動作に大きな影響を与えるパートナーを選択することになります。
前者はあなたに大きな影響を与え、後者はエンドユーザーに大きな影響を与えます。コンポーネント ライブラリを使用すると、そのコンポーネント ライブラリの標準に拘束されることになります。
このライブラリでは、メジャー バージョンに大規模な互換性を破る変更が導入される可能性があり、これには専用の開発時間が必要となる可能性があり、深刻な後退が発生しないことを確認するために多くのテストが必要になる可能性があります。
数年前、私は React Admin を使用して、社内部門向けの複雑な管理ダッシュボードを構築しました。このライブラリは、複雑なデータの取得と表示に特化した一連のコンポーネントを提供しました。当時のアプリケーションは React Admin に大きく依存していたため、特に React Admin で使用されていた内部ツールの多くが他のツールに置き換えられていたため、メジャー バージョン間のアップグレードは困難でした。変更面は非常に大きく、私たちはアップグレードと発見した問題の報告にかなりの時間を費やしました。
独自のソリューションを構築しても長期的には時間を節約できたとは思えませんが、この種のベンダー ロックインは、特にツールに全面的に取り組む前に検討する価値があります。
ショックなことですが、多くのコンポーネントを含むライブラリは、多くのコードを使用して作成される傾向があります。依存関係をインストールするときにダウンロードするコード、およびエンド ユーザーに送信するコード。
最新のツールを使用すると、未使用のコードを削除するツリーシェイキングなどのバンドルの最適化を簡単に実行できますが、ユーザーが必要としないコードをすべて削除しているという保証はありません。
使用しているライブラリを詳しく調べない限り、ライブラリがインポートしている個別のパッケージをすべて認識できない可能性があります。何百もの不要な依存関係が発生する可能性があります。 e18e コミュニティの人々は、この問題を明らかにするとともに、修正するために懸命に取り組んできました。
これらの問題の多くは、独自のコンポーネント ライブラリのローリングに関しても言えます。最大の違いは、コンポーネント ライブラリを管理できることです。特定の問題をどのように解決するかを定義でき、欠点の改善を制御できます。
World Wide Web の最初の提案は、CERN の研究者間のコミュニケーションを改善するツールでした。この提案では、ハイパーテキストを使用してドキュメントを共有し、相互にリンクする方法について概説しました。これはウェブの基本的な基礎であり、私たちは今でも謙虚な を使用しています。タグを使用して、Web 上の他の HTML ドキュメント間をリンクします。
しかし、ここ数十年でウェブの範囲は拡大し、ウェブをナビゲートするために私たちが使用するブラウザは、それ自体が猛獣になりました。今日のブラウザーは、強力な形式の創造的な表現と、ネイティブのようなソフトウェアの実行を可能にします。
世の中には、汎用的なものから超ニッチなものまで、何百もの異なるソリューションがありますが、次のプロジェクトに適切なツールを見つけるには、次のような複雑な意思決定プロセスが必要です。
これは、すべてのユースケースやコンポーネント ライブラリ タイプの包括的なリストではありませんが、次の点でコンポーネント ライブラリがどのように異なるかを示しています。
最も一般的なコンポーネント ライブラリのタイプをいくつか見てみましょう
?簡単な補足: 独自の Web コンポーネント ライブラリを構築することに興味がある場合は、私のコース Component Odyssey をチェックすることを検討してください。あらゆるフロントエンド フレームワークで動作するコンポーネント ライブラリを構築して公開する方法を学びます。
私にとって、最初に思い浮かぶのは Bootstrap です。昔は、サイトにちょっとしたペイントを加えたい場合は、CDN リンクをブートストラップ CSS ファイルにドロップすると、すぐにブートストラップの外観が得られました。 2010 年代半ばにはどこにでもありました。
この種のツールの技術的範囲は次のとおりです
へ
Open Props などの他の多数のツールは、その間のどこかに収まります。
インタラクティブな Web アプリケーションを構築している場合は、見栄えが良く、適切に機能する一連のコンポーネントを入手したいと思うかもしれません。必要なものすべてを提供する既製のコンポーネント ライブラリが多数あります。
アプリを作成するフレームワークに関係なく、使用できる見栄えの良いコンポーネントのセットが存在する可能性があります。
もう 1 つの優れたコンポーネント ライブラリは Shoelace です。これは、完全にインタラクティブで完全にスタイル設定されたコンポーネントを多数提供します。
Shoelace のようなライブラリが特に興味深いのは、ブラウザに組み込まれたコンポーネント作成方法である Web コンポーネントを使用して構築されていることです。 Shoelace などのツールを使用して UI を構築すると、さまざまなフロントエンド フレームワーク間で使用できるという追加の利点が得られます。これについては、私が過去に少し話したことがあります。
これは、Vue と React で使用されている同じ靴ひもコンポーネントです。
プロジェクトの仕様によっては、既製のツールを使用する余裕がない場合があります。あなたの設計仕様は非常に具体的である可能性があります。
摩擦の最初の兆候が現れると、チームがコンポーネントを転がすのを見てきました。また、手動のデータ ピッカーを使用したケースでは、ユーザー エクスペリエンスが大幅に低下しました。振り返ってみると、スタイルのないコンポーネント ライブラリを使用すると、チームは外観に柔軟性を与えながら、時間を確保できたでしょう
だからこそ、柔軟なスタイル設定フックを備えた完全にスタイル設定されていないコンポーネントを提供するライブラリを利用できるのです。優れたライブラリであれば、これらの複雑なやり取りもすべて処理してくれます。これは両方の利点を生かした状況です。
幅広いデバイスや入力モードでテストしない限り、ブラウザーが提供するスタイル フックを超えたものを押し込みたい場合は、チェックボックスを台無しにするのは簡単です。
元の記事には、スクリーン リーダーを使用してさまざまなチェックボックスの実装を操作する様子を示すビデオがあります
Radix はライブラリのよく知られた例ですが、React を使用して構築されています。
このようなコンポーネント ライブラリの他の例としては、Lion や HeadlessUI があります。
一部の開発者は、両方の長所を利用したいと考えているかもしれません。マークアップ、スタイル、機能を完全に制御しながら、信頼できるサードパーティ ライブラリによってコンポーネントが構築されることを望む場合があります。 ShadCN のようなライブラリでは、開発者がコンポーネント定義をコピーして自分のプロジェクトに貼り付けることができるため、この種のワークフローが可能になり、事実上コンポーネントを所有できるようになります。
この時点で、そのような単一コンポーネント ライブラリが存在しない理由はおそらく明らかです。私たちは、コンポーネント ライブラリのさまざまなグループについて非網羅的に検討してきました。
しかし、ブラッド・フロストが主導した概念である「グローバル・デザイン・システム」を導入しようとする動きがある。
発表の中で、ブラッドは、これまで参加してきた何百ものプロジェクトにおいて、UI コントロールの多くがこれらのさまざまなプロジェクト間で同様に動作する (または動作するはずである) にもかかわらず、開発者はすべてのプロジェクトで同じものを再実装していると概説しました。これにより、多くの時間と労力が無駄になり、プロジェクト間の不一致が生じています。これは、既存のコンポーネント ライブラリにも拡張されます。 React Aria のコンボボックスのキーボード動作が ShadCN のコンボボックスの動作とは異なることがわかります。
元の記事には、キーボードを使用してさまざまなコンボボックス実装を操作する様子を示すビデオがあります
Brad Frost は、HTML でまだ利用できないコントロールの機能のベースラインを確保するために、ほとんどすべてのフロントエンド プロジェクトで採用できる Web コンポーネントのセットとしてグローバル デザイン システムを提案しています。
オープン UI 内では、今後数年以内にこれがどのように形になり始めるかについて議論が行われています。
この記事はコンポーネント ライブラリについて幅広く掘り下げたものであり、これらすべてのコンテキストを考慮すると、次の大きなプロジェクトの空の HTML ページを見つめるとき、独自のコンポーネント ライブラリを構築するか、それとも既存のもの。
私の最初の考えは次のとおりです: ライブラリを構築する必要はないと思います。
私は通常、実戦でテストされたライブラリを選ぶことを好みます。特に次のようなもの:
これらすべての中で最も重要なことは、コンポーネント ライブラリを使用して、アクセス可能なコンポーネントの構築に注意を払うことです。
コンボボックスを例に考えてみましょう。検索入力と選択メニューが 1 つになったものです。独自に作成した場合は、見栄えがよく、マウスで操作できるかもしれません。ただし、次のことも考慮する必要があります。
Web + Web コンポーネントの分野で優れた仕事をしている Konnor Rogers は、アクセシブルなコンボボックスを構築した経験について数え切れないほどの不満を共有しています。これが彼がシェアしたツイートの 1 つです。
スクリーン リーダーのサポートは特に複雑であり、独自の箇条書きリストを作成する価値があります。スクリーン リーダーをサポートするには、以下も処理する必要があります:
余談ですが、私は Voiceover にしかアクセスできないため、さまざまなスクリーン リーダーを使用してこれらの複雑な UI パターンをテストするのは困難です。ブラウザと同様、スクリーン リーダーにも違いがあります。この記事「Are We Live?」では、Scott O'Hara が、ライブ領域の扱い方の違いにどのような差異があるかを説明しています。
これは、アクセシビリティを念頭に置いて開発された信頼できるコンポーネント ライブラリを選択するのも開発者次第であることを意味します。このため、強力なコミュニティを持つコンポーネント ライブラリを選択することも重要です。次のことができることが重要です:
最後に、重要なことですが、優れたコンポーネント ライブラリでは、コンポーネントの美しさ以上のものを考慮します。 Web 用に設計されたコンポーネント ライブラリの場合、次のことを最善の方法で行う必要があります。
コンポーネント ライブラリの構築を怖がらせていないのであれば、自分自身に反論して、独自のライブラリを構築することがなぜ本当に良いことなのかを説明させてください。
コンポーネント ライブラリの構築に十分な注意と時間をかけて取り組めば、ブラウザ プラットフォーム、アクセシビリティのベスト プラクティス、テスト方法などをより深く理解できる開発者になることができます。
しかし、それだけではありません。独自のライブラリを構築する優れた理由がいくつかあります。
まず、ニーズに合わせたものを構築し、既製のコンポーネント ライブラリから生じる可能性のある肥大化を回避できます。エンド ユーザーを理解できるかどうかはあなたとあなたのチーム次第であり、エンド ユーザー向けに特別なものを構築することもできます。
新しいアプローチを実験する機会もあります。非常にニッチな問題がある場合、そのニーズを解決するコンポーネント ライブラリが存在しない可能性があります。それは次のようなコンポーネント ライブラリである可能性があります:
これにより、ニーズに合わせたものを構築する機会が得られます。その後、ニーズの変化に応じて、または問題領域をより深く理解するにつれて、物事を変更したり修正したりする機会が得られます。
重要なことは、そうすることでウェブについてさらに学ぶことができるということです。初めてコンポーネント ライブラリを構築する場合は、HTML ブラウザの仕様をさらに深く掘り下げたり、Web アクセシビリティの知識をブラッシュアップしたりする機会になる可能性があります。これにより、Web 開発者としての能力が向上し、将来的にはあらゆるフロントエンド プロジェクトで役立つでしょう。次の仕事を見つけるのにも役立つかもしれません。
したがって、コンポーネント ライブラリを構築する必要があるかどうかは、最終目標によって異なります。次のような質問を考えてみましょう:
答えに応じて、プロジェクトに適切な判断を下すことができます。
読んでいただきありがとうございます!独自の Web コンポーネント ライブラリの構築に興味がある場合は、私のコース Component Odyssey をチェックしてみてください。あらゆるフロントエンド フレームワークで動作するコンポーネント ライブラリを構築して公開する方法を学びます。
以上がコンポーネント ライブラリとは何ですか? 独自のライブラリを構築する必要がありますか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
