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

# スタイルと CSS
<a name="styling-css"></a>

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

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

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

## システムを設計する ‒ 何かを共有するアプローチ
<a name="design-systems"></a>

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

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

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

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

欠点は、あらゆる種類の設計システムが依存関係であるため、維持し、場合によっては更新する必要があることです。複数のマイクロフロントエンドで共有依存関係の新しいバージョンが必要な場合は、次のいずれかを使用できます。
+ 競合することなく、その共有依存関係の複数のバージョンを取得できるオーケストレーションメカニズム
+ すべての依存関係を移動して新しいバージョンを使用するための共有戦略

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

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

## 完全にカプセル化された CSS ‒ 何も共有しないアプローチ
<a name="encapsulated-css"></a>

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

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

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

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

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

## 共有グローバル CSS ‒ 共有オールアプローチ
<a name="shared-global-css"></a>

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

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

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