はじめに

こんにちは！Incremental Stream Team の @53able です！

GameWithのリプレイスについて第3回目の記事である今回は、 GDS(GameWith Design System) の根底にある方針や考え方について書いていきたいと思います。

前回の記事はこちらから御覧ください

GDS が目指しているもの

GDS は前回のブログでも書いたように、下記のような世界を目指しています。

どんなプロジェクトでも簡単に利用できるHTMLコンポーネントの提供

GDS では Web Components というWeb標準技術を利用して、HTMLコンポーネントを提供しています。

Web フロントエンドアプリケーションを開発する際に考えられるのは Vue や React や Angular などといったフレームワークがあげられます。

これらのフレームワークで開発を行った場合、例えば Vue を採用した際に、React のアプリケーションにコンポーネント提供した場合かなり困難であると考えられます。

そのため、Web 標準である Web Components のコンポーネントモデルを導入することで、様々なフレームワークで書かれたコンポーネントアプリケーションを開発していくとにしました。

提供をしている Web Components は自己完結型です。

そのため、コンポーネントは他のコンポーネントに影響を与えることなく修正し、アップグレードしていくことが可能です。

GDS は僕たちのチームで構築をし開発を行いましたが、ドメインの異なるチームでも積極的に利用をはじめています。

今までの GameWith の開発サイクルやリリースの仕組みなどと分離されているため、他のチームでも利用しやすいです。

例えばあつ森 (あつまれどうぶつの森) 攻略記事でリリースしたツールは GDS を利用して、攻略記事チームが開発をしました。

このあつ森のツールは GameWith というアプリケーション内にある、独立したフロントエンドアプリケーションのような動きをします。

以上のことから今後もGDSをGameWithサービス内でスケールさせていきたいと考えているので、このアーキテクチャによるメリット/デメリットを上げておきます。

古いブラウザではサポートされていません。ポリフィルは存在しますが、重くて、経験則に基づいた実装になっているため、根本解決にはなりません
動作するには JavaScript が必要です
プログレッシブエンハンスメントはありません
サーバーサイドレンダリングは今、 Declarative Shadow DOM という仕様が策定されており将来的に気軽にできるようになるかもしれませんが、まだ一般的はないようです
- https://web.dev/declarative-shadow-dom/
異なる Shadow DOM 間で共通のスタイルを共有するのは難しい
Bootstrap のようなグローバル CSS クラスを使用するスタイリングアプローチでは動作しません