マイクロフロントエンドとデザインシステムのドリフト: チーム間で UI の一貫性を保つ
マイクロフロントエンドを使用するチームが 1 つの一貫した UI を維持する方法: バージョン管理されたパッケージとしてのトークンとコンポーネントの共有、CSS の分離、アップグレード ポリシー、視覚的な回帰チェック。
核心
マイクロフロントエンドを使用すると、チームが製品の一部を個別にデプロイできるため、コンポーネントの異なるバージョン、CSS の競合、スタイルの重複など、UI のドリフトが発生しやすくなります。設計トークンとコンポーネントをバージョン管理されたパッケージとして共有し、各チームの CSS を分離し、アップグレード ポリシーに同意し、視覚的な回帰テストで相違点を把握することで、一貫性を維持します。
なぜドリフトが起こるのか
Martin Fowler のサイトでは、マイクロ フロントエンドについて、大きな全体として構成された独立して配布可能なフロントエンド アプリケーションとして説明しており、独立した展開が主な利点となります。同じ独立性がドリフトを引き起こします。チームは異なるタイミングでデザイン システムをアップグレードし、より速く動作させるためにコンポーネントをコピーし、ページの他の部分に漏れ出る CSS を記述します。この記事では、一部の実装では依存関係が重複していること、CSS はグローバルでカスケード型であるため、意図的な分離が必要であることも警告しています。
システムをパッケージとして共有する
トークンとコンポーネントを、コピー＆ペーストしたコードではなく、バージョン管理されたパッケージとして公開します。 W3C DTCG 形式などの標準形式のトークンは、チームが使用するフレームワークごとに構築できるため、React チームと Vue チームは同じ色、間隔、モーションを共有します。
CSS を分離
BEM、CSS モジュール、CSS-in-JS、Web コンポーネントの Shadow DOM などの命名規則など、一貫したアプローチにより、チーム間でのスタイルの漏洩を防ぎます。製品全体の規則を 1 つ選択し、その規則をリントします。
アップグレードポリシー
チームがどの程度遅れてもよいか (メジャー バージョンを 1 つまでにするなど) に同意し、セマンティック バージョニングを使用して、いつ変更が中断されるかをチームが認識できるようにします。各マイクロフロントエンドが共有ダッシュボードで使用するバージョンを追跡します。
ドリフトを自動的にキャッチ
主要な画面での視覚回帰テスト、生の色と間隔の値を禁止する lint ルール、および共有サーフェス (ヘッダー、ナビゲーション、チェックアウト) でのデザイン レビューにより、ユーザーが目にする前に矛盾を発見します。
覚えておきたい原則
- 独立した展開により UI のドリフトが発生しやすくなる
- トークンとコンポーネントをバージョン管理されたパッケージとして共有する
- 1 つの一貫したアプローチで CSS を分離する
- アップグレードポリシーに同意し、バージョンを追跡する
- 視覚的な回帰テストと lint ルールを使用する
よくある質問
出典
- Micro Frontends — martinfowler.com
- Design Tokens Community Group — デザイントークン.org
- Semantic Versioning 2.0.0 — semver.org