私のプロダクトの独自AtomicデザインとComponent構成
この記事では私が業務で開発しているプロジェクトのAtomicデザインの考え方とComponentの構成について紹介します。
一部独自の構成になっていますが、あくまで紹介なのでこの構成をゴリ押しするつもりはまったくございません。
こういう考えもありなんだくらいに捉えていただければと思います。
また、この構成は私が考えたのではなく、すでに弊社を退職されてしまった方が考えてくださった構成です。
その方に敬意を表しつつ紹介できればと思いますので、最後まで読んでいただけたら幸いです。
この記事で伝えたいこと
- Atomicデザインの独自の解釈とそのメリット
- 運用していく上での課題感と今後の展望
本題
Atomicデザインを導入したねらい
現在運用しているプロダクトを開始する際に以下を実現したいと思っていました。
- コンポーネントの責務を明確にしたい
- 依存関係を明確にしたい
上記はよくある一般的な目的だと思いますが、それを実現するためのHowとしてAtomicデザインを採用しました。
どちらも現状実現できていて、運用としてしっかりと回すことができています。
Atomicデザインの分け方と役割、原則
Atoms
- どのサイトでも使用できるような汎用的なコンポーネントであること
- どのコンポーネントにも依存しないこと
- ドメイン知識を有さないこと
Molecules
- どのサイトでも使用できるような汎用的なコンポーネントであること
- Atoms、Molecules以外に依存しないこと
- ドメイン知識を有さないこと
Organisms
- このプロダクトでのみ使用する前提でドメイン知識を有すること
- Atoms、Molecules、Organisms以外に依存しないこと
- APIを介さないこと
Organizations
- Organismsの描画に必要な情報を取得して注入するロジック層であること
- cssは使用禁止
Templates
- 下位のコンポーネントを利用して1ページとして機能するコンポーネントであること
- APIやglobal contextへの直接参照は禁止
Pages
- Templatesの描画に必要な情報を取得して注入するロジック層
- cssは使用禁止
上記の通り、一般的なAtomicデザインには存在しない Organizations というロジック層を独自に定義しています。
私のプロダクトでは React Query と Recoil を使用していて、React QueryはPagesで使用し、RecoilはOrganizationsで使用する分け方をしています。
Recoilはプロダクト全体で管理したい情報を保持する目的で、例として会員情報などを管理します。
OrganismsでRecoilを使用するコンポーネントと使用しないコンポーネントが混在するのを避けるために、Organismsよりも上位の概念を定義しました。
Organizationsという命名はOrganismsの上位という意味合いであり、わかりやすくてOrganismsより上位というのが明確になればなんでもよかったです。
通常のAtomicデザインに1つ追加することによって、よりロジックの所在が明確になり、OrganismsはよりUIの描画に専念することができます。
また、テストに関してもOrganizationsとPagesにはロジックのテスト、Atoms、Molecules、Organisms、Templatesにはスナップショットテストとテストの所在も明確に分けることができました。
Atomicデザインの考え方
Atomicデザインは5つの分類にUIを分けることを提唱していますが、私達は独自の考え方と分け方を採用しました。
多少強引な考え方かもしれませんが、原則を一定守ったルールとチーム内での共通認識が取れていれば、アレンジを加えることは運用を回していく上でかなり効果的な一手となりうると思います。
私のプロダクトはリリースから一定の期間が経ってある程度運用を回している時期になりましたが、責務分担を明確にしたことによって、チーム内の理解度と練度もあがってきて健全に運用を回すことができる体制が整ってきました。
現状の課題感と展望
運用が回るようになってきた一方で、課題感も出てきました。
1つ目は、AtomsとMoleculesを分けることの旨味が薄いことです。
ドメイン知識を持たない汎用的なコンポーネントという点で共通していますが、サーバーサイドをバックグラウンドに持つ人がフロントエンドを実装する際に、そこの分け方はわかりにくいことが多く、苦労して分けたところであまり恩恵を得られないなと感じることが多くなりました。
この課題に関してはUIといったより汎用的な命名にしてAtomsとMoleculesをまとめようかと考えています。
デザイナーともUIをインターフェイスに会話し、社内のデザインシステムやUIライブラリとして提供できるようなものにしたいという密かな展望があります。
もしくは別レポジトリに切り出してnpmパッケージとして展開し、実プロダクト内部では実装しないとしてもよいかもしれません。
2つ目は、Organismsの肥大化です。
機能追加によってページが増えることによって相乗的にOrganismsも増えてきて、Atomsの倍以上のコンポーネントが存在しています。
また特定のページでしか使われないコンポーネントと、複数のページで使用されるコンポーネントが出てきて、そこを分けたいと感じることもでてきました。
複数ページで使われるOrganismsは、ドメイン知識をpropsで注入してMoleculesとして定義することもできはしますが、Moleculesは汎用的なUIライブラリとして定義したいため、やはりOrganismsに配置することが多いです。
そのためOrganismsが煩雑になり、とりあえずOrganismsに置くかというなんでもディレクトリになってきてしまっています。
Organisms内部はよりドメインに寄り添ったディレクトリ構成にしてもいいかもしれません。
共通で使うドメイン知識を有したコンポーネントは、shared等に切り出すとより責務が明確になるかなーとも思っています。
まとめ
本記事は実運用しているプロダクトでの構成とメリットと課題感の紹介でした。
Atomicデザインは世間的にも浸透してきていて、デザイナー・エンジニア間での会話もしやすくメリットの大きいデザインシステムだと思います。
実際きれいに運用を回すことができていますし、導入したことは私のプロダクトでは成功であったと言えると思います。
今後すぐすぐ構成を変更するということはないかもしれませんが、現状に留まることは退化だと思っているので、チーム内でディスカッションを行い、より運用の回しやすい責務の明確になった構成を目指していきたいと考えています。
なにか進展があったらまた記事にできればと思います。
ここまで読んでいただき、ありがとうございました。
Discussion