スタイリングと CSS - AWS 規範ガイダンス

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

スタイリングと CSS

カスケードスタイルシート (CSS) は、テキストとオブジェクトの書式をハードコーディングするのではなく、ドキュメントの表示を一元的に決定するための言語です。言語のカスケード機能は、継承を使用してスタイル間の優先順位を制御するように設計されています。マイクロフロントエンドで作業し、依存関係を管理する戦略を作成する場合、言語のカスケード機能は難しい場合があります。

例えば、2 つのマイクロフロントエンドが同じページに共存し、それぞれが HTML body 要素の独自のスタイルを定義します。それぞれが独自の CSS ファイルを取得し、styleタグを使用して DOM にアタッチする場合、共通の HTML 要素、クラス名、または要素 IDs。これらの問題に対処するには、スタイルを管理するために選択する依存関係戦略に応じて、さまざまな戦略があります。

現在、パフォーマンス、一貫性、デベロッパーエクスペリエンスのバランスをとる最も一般的なアプローチは、設計システムの開発と保守です。

システムを設計する ‒ 何かを共有するアプローチ

このアプローチでは、システムを使用して、必要に応じてスタイルを共有し、時折の発散をサポートして、一貫性、パフォーマンス、デベロッパーエクスペリエンスのバランスを取ります。設計システムは、明確な標準に基づいて再利用可能なコンポーネントのコレクションです。設計システムの開発は通常、多くのチームからのインプットと貢献を持つ 1 つのチームによって推進されます。実際には、設計システムは、 JavaScript ライブラリとしてエクスポートできる低レベルの要素を共有する方法です。マイクロフロントエンドデベロッパーは、事前に作成された利用可能なリソースを作成し、新しいインターフェイスを作成するための出発点として、ライブラリを依存関係として使用してシンプルなインターフェイスを構築できます。

フォームを必要とするマイクロフロントエンドの例を考えてみましょう。一般的なデベロッパーエクスペリエンスは、設計システムで使用可能な事前に作成されたコンポーネントを使用して、テキストボックス、ボタン、ドロップダウンリスト、その他の UI 要素を構成することです。デベロッパーは、実際のコンポーネントの外観についてのみ、スタイル設定を記述する必要はありません。構築およびリリースするシステムは、Webpack モジュールフェデレーションまたは同様のアプローチを使用して設計システムを外部依存関係として宣言できるため、フォームのロジックは設計システムを含めずにパッケージ化されます。

その後、複数のマイクロフロントエンドが同じ操作を行って、共有された懸念に対処できます。チームが複数のマイクロフロントエンド間で共有できる新しいコンポーネントを開発すると、それらのコンポーネントは成熟後に設計システムに追加されます。

設計システムアプローチの主な利点は、高いレベルの一貫性です。マイクロフロントエンドはスタイルを記述し、設計システムからスタイルを上書きすることがありますが、その必要性はほとんどありません。主な低レベル要素は頻繁に変更されず、デフォルトで拡張可能な基本的な機能を提供します。もう 1 つの利点はパフォーマンスです。構築とリリースの優れた戦略により、アプリケーションシェルによって実装される最小限の共有バンドルを生成できます。複数のマイクロフロントエンド固有のバンドルがオンデマンドで非同期的にロードされ、ネットワーク帯域幅のフットプリントが最小限に抑えられる場合、さらに改善できます。最後に、デベロッパーエクスペリエンスは理想的です。これは、ユーザーがホイールを再考案することなく、リッチインターフェイスの構築に集中できるためです (ボタンがページに追加されるたびに CSS JavaScript を記述するなど)。

欠点は、あらゆる種類の設計システムが依存関係であるため、維持し、場合によっては更新する必要があることです。複数のマイクロフロントエンドで共有依存関係の新しいバージョンが必要な場合は、次のいずれかを使用できます。

  • 競合することなく、その共有依存関係の複数のバージョンをフェッチできるオーケストレーションメカニズム

  • すべての依存関係を新しいバージョンを使用するように移行する共有戦略

例えば、すべてのマイクロフロントエンドが設計システムのバージョン 3.0 に依存しており、共有方式で使用する 3.1 という新しいバージョンがある場合、すべてのマイクロフロントエンドに機能フラグを実装して、最小限のリスクで移行できます。詳細については、「機能フラグ」セクションを参照してください。もう 1 つの潜在的な欠点は、設計システムが通常、スタイル設定よりも多く対処することです。また、 JavaScript プラクティスやツールも含まれます。これらの側面では、議論とコラボレーションを通じて合意に達する必要があります。

設計システムの実装は、長期的な投資として最適です。これは一般的なアプローチであり、複雑なフロントエンドアーキテクチャに取り組んでいるすべての人が検討する必要があります。通常、フロントエンドのエンジニア、製品および設計チームが協力して相互にやり取りするメカニズムを定義する必要があります。目的の状態になるまでの時間をスケジュールすることが重要です。また、長期的に信頼性が高く、適切に維持され、パフォーマンスの高いものを構築できるように、リーダーシップからスポンサーシップを受けることが重要です。

完全にカプセル化された CSS ‒ 何も共有しないアプローチ

各マイクロフロントエンドは、規則とツールを使用して CSS のカスケード機能を克服します。例としては、各要素のスタイルが常に要素の ID ではなくクラス名に関連付けられ、クラス名は常に一意であることが挙げられます。このようにして、すべては個々のマイクロフロントエンドに限定され、不要な競合のリスクが最小限に抑えられます。アプリケーションシェルは通常、マイクロフロントエンドのスタイルを DOM にロードした後、ロードしますが、一部のツールは を使用してスタイルをバンドルします JavaScript。

何も共有しない主な利点は、マイクロフロントエンド間で競合が発生するリスクを減らすことです。もう 1 つの利点は、開発者の経験です。各マイクロフロントエンドは、他のマイクロフロントエンドと何も共有しません。単独でのリリースとテストは、より簡単かつ迅速です。

共有なしアプローチの主な欠点は、一貫性の欠如の可能性です。整合性を評価するシステムはありません。共有内容の複製が目標であっても、リリースとコラボレーションのスピードのバランスをとると困難になります。一般的な緩和策は、整合性を測定するツールを作成することです。例えば、ヘッドレスブラウザを使用してページにレンダリングされた複数のマイクロフロントエンドの自動スクリーンショットを撮るシステムを作成できます。その後、リリース前にスクリーンショットを手動で確認できます。ただし、これには統制とガバナンスが必要です。詳細については、「調整による Balancing の自律性」セクションを参照してください。

ユースケースによっては、パフォーマンスがもう 1 つの欠点となる可能性があります。すべてのマイクロフロントエンドで大量のスタイルを使用する場合、お客様は重複したコードを多数ダウンロードする必要があります。これはユーザーエクスペリエンスに悪影響を及ぼします。

この共有なしのアプローチは、少数のチームのみを含むマイクロフロントエンドアーキテクチャ、または低い一貫性を許容できるマイクロフロントエンドでのみ考慮する必要があります。また、組織が設計システムに取り組んでいますが、これは自然な最初のステップになることもあります。

共有グローバル CSS ‒ 共有オールアプローチ

このアプローチでは、スタイル設定に関連するすべてのコードが中央リポジトリに保存され、寄稿者は CSS ファイルを操作するか、Sass などのプリプロセッサを使用してすべてのマイクロフロントエンドの CSS を書き込みます。変更が行われると、ビルドシステムは CDN でホストし、アプリケーションシェルによって各マイクロフロントエンドに含めることができる単一の CSS バンドルを作成します。マイクロフロントエンドデベロッパーは、ローカルでホストされるアプリケーションシェルを介してコードを実行することで、アプリケーションを設計および構築できます。

このアプローチの利点は、マイクロフロントエンド間の競合リスクを軽減するという明らかな利点とは別に、一貫性とパフォーマンスです。ただし、マークアップやロジックからスタイルを切り離すと、デベロッパーはスタイルの使用方法、進化する方法、廃止方法を理解するのが難しくなります。例えば、既存のクラスとそのプロパティを編集した場合の結果について学ぶよりも、新しいクラス名を導入する方が速い場合があります。新しいクラス名を作成するデメリットは、バンドルサイズの増加です。これはパフォーマンスに影響し、ユーザーエクスペリエンスに不整合が生じる可能性があります。

共有グローバル CSS は移行の出発点 monolith-to-micro-frontendsになる可能性がありますが、複数のチームや 2 つのチームが連携するマイクロフロントエンドアーキテクチャにとって有益であることはほとんどありません。設計システムの開発中は、できるだけ早く設計システムに投資し、共有なしのアプローチを実装することをお勧めします。