React NativeとAtomic Designの相性がよくなかった話
こんにちは、Undefinedのアプリエンジニアの塚本武志(https://twitter.com/itometeam)です。
弊社ではiOS/Android側のアプリ開発にReact Nativeを採用しています。
React Nativeに限らず、画面数が多いアプリ開発ではViewの管理が開発のスケーラビリティのために重要になります。
React Nativeはまだ新しく、採用しているプロダクトも少ないため、まだ運用のグッドプラクティスがコミュニティに蓄積されていないのが現状です。今回は、Viewの管理についてReactでは一般的になりつつあるAtomic DesignをReact Nativeプロダクトに導入してみてわかったメリットとデメリットを書いておきます。
Atomic Designとは
Atomic DesignはコンポーネントをAtoms/Molecules/Organisms/Templates/Pagesと粒度によって5種類に分け管理するデザイン手法で、Webアプリの実装ではすでに一般的になりつつあります。Android/iOSでよくあるViewが所属するドメイン単位(Activity, ViewController単位)でのViewの管理に対して、再利用の際の可搬性を考慮した切り分けができるのが特徴です。
React Nativeプロジェクトでの運用方法
基本的にはReactを採用しているプロジェクトと同じようにAtomsなどの単位ごとにディレクトリを作り、その中にそれぞれコンポーネントを実装していくようにしましたが、React Nativeとの相性を考慮して以下のような変更を加えています。
PagesをScreensに
画面遷移にreact-navigation(https://reactnavigation.org/)を使っているので、命名をライブラリのスタンダードな使用例に合わせる目的で名前をScreensに変更しました。。
TemplatesをContainersに
React Nativeではワイヤーフレーム的なViewの単位は不要と考え、代わりにReduxと接続したり子Viewのstate管理のためのContainerを入れました。
なにが問題だったか
Viewの数の増加
前に書いたようにAtomic Designのメリットにドメインに縛られないViewの管理ができることが挙げられますが、Webアプリよりも画面数が多くなる傾向にあるネイティブアプリ開発だとViewの数が増えすぎて逆に管理がしづらくなります。
ネイティブアプリ特有のデザインとの相性の悪さ
ネイティブアプリはスワイプを前提としてデザインされるため、画面一枚に対して連続的に内容が切り替わるデザインが多く用いられます。例えばインスタグラムのストーリーのスワイプ切り替えや、AndroidのViewPagerを使ったデザインなどです。これらはデザイン上は連続的に切り替わる画面として扱われますが、実装の段階では一つの親Viewに属する複数の子Viewとして扱われなければなりません。このデザインと実装の違いがTemplateとPageの違いを曖昧にしてしまいます。
Organismsが口に出すとなんかエッチな単語に聞こえてメンバーが言いよどむ
コミニケーションコストが増大します。
Organism(生体)は普段聞きなれない言葉なのに、音が近い単語がそういう意味なせいでなんか口に出しづらい感じがします。Googleで「オーガニズム」と検索すると他方が引っかかります。
結局どうしたか
Atomic Designの導入はやめにしました。
現在は画面との凝集度が高いViewに関して画面毎に管理し、それ以外の再利用可能コンポーネントを粒度によってComponentとContainerに分けて管理しています。画面に限定されたViewが増える分Atomic Designより再利用性は下がりますが、React Nativeはあとでコンポーネントの切り分けをするのも簡単なので、設計理念と運用のバランスをとった形になります。
最後に
今回のプロジェクトではAtomic Designの採用をやめましたが、今回遭遇した多くの問題は、デザインの方針・メンバーの練度・ビジネスロジック側で採用しているフレームワークによって変わるものばかりなので、もしReact Native + Atomic Designでの運用事例、実装例などありましたら、こちら(https://twitter.com/itometeam)に教えていただけると幸いです。
