チームで行うReact Componentの設計

こんにちは。DMM.comでフロントエンド開発を行っている@ma9toです。
DMMでは各プロダクト毎でフロントエンドの技術選定が違いますが、私が担当しているしているプロダクトでは、一部Reactを採用しています。

この記事では、ReactのComponentの設計をチームで行ったときの反省と、次はどのように行うと良さそうか、現時点で思うところをまとめておこうと思います。

Componentとは

まず、Componentとはどういうものか振り返っておきたいと思います。
Componentとは、UIを構成する一部分と考えることができます。
ReactはComponentを組み合わせることので、より複雑なUIを構築していくようなComponentベースのViewライブラリです。
Reactを利用することで、Componentのコードのカプセル化を容易にし、独立したComponentの実装を可能にしてしてくれます。

Atomic DesignでComponentを整理する

チームでComponentを作成する場合、Componentの粒度や構成を予め明確にし、言語化しておくことで、メンバーが共通認識を持ち、結果Componentが整理されることで、保守性が良くなります。

私の所属チームはAtomic Designを採用しましたが、目的は設計指針を明確にして、整理されたComponentにすることです。
私はAtomic Designが最適解だとは思っていませんが、Component設計の指針にするには利用しやすい原理だと思っています。

	構成	定義方法	state	再利用性
Atoms	それ以上に分解ができない	Functional Component	もたない	高
Molecules	AtomsとAtomsの組み合わせ	Functional Component	もたない	中
Organisms	MoleculesとMoleculesまたは、Moleculesとatomsの組み合わせ	Class Component	もつ	低またはない
Templates	Organismsの組み合わせ	Class Component	もつ	ない

ただ、今回失敗したのは、AtomsとMoleculesの検討を十分に行えなかったことです。
再利用性の高いComponentとしてAtomsやMoleculesを用意しておきたかったのですが、UIデザインがある程度固まった状態でのComponentの定義だったため、再利用性が低いComponentの数が想定していたよりも多くなってしまいました。

Componentの定義をチームで行う

Component設計の指針は明確になりましたが、Componentの定義はその定義者のスキルセットや情報の格差などによって、少なからず定義者の偏見が入る余地があります。そういった偏見を排除するためにチームで行うことによってより洗練されたComponent定義ができると思います。

私の所属チームではデザインカンプを印刷し、チームで話し合いながらComponentをハサミで切り抜き、グループわけをしてComponentに付箋で名前をつけていきました。

デザイナーとフロントエンドエンジニアで行って、ワイワイ楽しい感じでできました。
このときは、できなかったのですが、アプリケーション全体の設計をフロントエンドから行う場合であれば、この時点でサーバーサイドエンジニアを含めて、チームでComponentのStateを洗い出し、Component間のやりとりを明確にすることで、API設計やComponentの実装が行いやすくなると思います。

まとめ

一人の開発者がデザインを含めたアプリケーション全体を見渡して、開発する場合は別として、大抵はチームで開発を進めます。
設計の指針を明確にし、チームを巻き込んで行うことで、よりよいComponentの設計ができるのではいかと思っています。

明日は@sasakipochiさんです。お楽しみに〜。