オレオレAtomic DesignとReactの相性
最近、Webのフロントエンドの世界ではReactを使っているプロジェクトがたくさんあってよく目にします。npmのトレンドで見ても圧倒的って感じではありますね。
今回は、Atomic DesignとReactの相性は結局いいのか。みたいなところとかどう言う辛さが待っているか、どのようにすればエンジニアもAtomic Designを使いやすくできるかみたいなことを記事にできたらと思います。
Atomic DesignでのReactコンポーネント
コンポーネント思考が当たり前になりつつあるこのフロントエンドの業界の中、Atomic Designでコンポーネントの管理を行っているプロジェクトは少なくないと思います。
しかし、もともとエンジニアに向けて作られたものではないので実装面で少し辛いところがあったりもするかと思います。
例えば、atomsにselectを作ったとします。selectは指定された選択肢の中から何かを選ぶときのUIの部品として使われますが、もしこの選ぶものがAPIのデータから生成するものだとすれば、pages -> templates -> organisms -> molecules -> atomsのようにpropsのバケツリレーが半端なくなったりします。わかりやすい例を出しましたがこの他にもいくつかバケツリレーがしんどくなる例がたくさんあると思います。
なぜバケツリレーが起こるかと言うと、Atomic Designの中ではPages以外はデータを持っていないからです。静的に作成できるselectであれば、moleculesのときに書いているので1段階のpropsだけです済みましたが、APIからデータを取ってきてそれを元にレンダリングするのであればpagesからpropsで渡していくのがAtomic Designにハマったやり方ではないかと考えています。
こう行った特殊ケースをAtomic Designではどのように許容したらいいのかを考えていくのがオレオレAtomic Designです。
Step1: 共通のコンポーネントなんだけど直接データのfetchをしたい
さっきのselectのような場面です。
その他にも、Header内にユーザーデータがある場合とかもPageでfetchしたものをpropsで渡すのはしんどいです。
こう言う場合の為に、僕はreceptorと言うディレクトリをつくりました。
とりあえずAPIを刺激として、化学に関係ありそうな名前を取ってきました（特に関係あるかもわかりません、すいません。）
このreceptorをpages以外に特別にデータを扱えるコンポーネントとしてつくりました。こうすることで、無理やりAtomic Designを意識しすぎて疲れることなく運用もできています。
Step2: そもそもAtomic Designから離れてみる
まずこのデザイン思考は、小さいチーム（フロントエンド2名）とかで0から作っていく時はルールをもう1つ追加するだけでUIも作りやすくなるのではないかと考えました。
現在のオレオレAtomic DesignではPageでのAPIのfetchが走って非同期の処理が完了するまでローディング画面が出ています。しかし、せっかく非同期でAPIを叩いているのに画面全部がローディングではかっこよくないのではないか。と考えました。
そこで僕は、Pages以外にreceptorをつくっていた構成をやめてそもそもOrganismsでAPIのfetchを行えば、ローディングをOrganisms単位で行うことができてページのViewがでるのを早めることができるのと部分的なリロードもやりやすいのではないかと思います。
以前までの構成
APIサーバーと通信をして404ならば、404のページのtemplateを返し200ならデータをreduxでconnectしてpropsで渡す方式です。
オレオレAtomic Designでの構成
こうすることでAPI側もクライアントに依存しづらいリソースに対してRestfulなAPIの設計ができるのではないか、Reducerの分け方もドメインでつくれたり管理もPageで跨ってたデータも管理がしやすくなるメリットもあるかなと思います。
Atomic DesignをReactで乗りこなすには
atomsからのディレクトリ構成や、それぞれの大きさの粒度の判断としてだけAtomic DesignをいれてOrganismsでデータのfetchを行うようにする。
この1点のルールを追加すると、例えば記事の一覧画面を作るのにももうそのコンポーネントを配置している場合スタイルもデータもはいっている状態と言うのがつくれて、より実用性のあるコンポーネントになれるのではないかと思います！