Edited at

チームで行うReact Componentの設計

More than 1 year has passed since last update.

こんにちは。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に付箋で名前をつけていきました。

Component2.png

デザイナーとフロントエンドエンジニアで行って、ワイワイ楽しい感じでできました。

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


まとめ

一人の開発者がデザインを含めたアプリケーション全体を見渡して、開発する場合は別として、大抵はチームで開発を進めます。

設計の指針を明確にし、チームを巻き込んで行うことで、よりよいComponentの設計ができるのではいかと思っています。

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