【React】Atomic Components を実践してみた

皆様こんにちは。　ゴスケです。

最近、Reactで開発する際のコンポーネント設計にAtomic Componentsを参考にしたのですが、色々悩むことが多かったです。

ということで、今回はAtomic Componentsで悩んだ事を振り返って行こうと思います。

Atomic Components

Atomic Designの派生で提唱されたコンポーネント設計です。
Atomic DesignではPresentational Componentはいいとして、Container Componentはどうするのかが疑問でした。
単純に考えるとmolecureやorganismにpresentationalとcontainerのフォルダを作るですが、なんかContainer Componentが浮いてる気がして腑に落ちないでいました。
そんなときに見つけたのがAtomic Componentsの解説記事です。
【参考】https://qiita.com/kahirokunn/items/b599d2cf04d2580c412c

これだ！と感じたのはecosystemですね。
自分が悩んでいたContainer Componentの取り扱い方がとても明確になっています。
これはいいと思い、早速これに則ってコンポーネント設計していったのですが、意外と悩む点がありました。。。

これはatom？molecule？organism？

Atomic Designあるあるの問題ですね。
人によって捉え方がわかれる上に「ルールを守る」ことが目的化してしまう厄介な問題です。
例えばButtonはAtomですが、Submit Buttonは？いいね Buttonは？となります。
この問題はプロジェクト毎に方針を決めるしかないと思います。

organismはecosystemを参照してもいい？

自分の場合、Formでこの状況になりました。
当時、FormをAtomic Componentで作る場合

• molecule　→　Input.jsx、SelectBox.jsx….
• organism　→　PresetationalForm.jsx
• ecosystem　→　ContainerForm.jsx

こんな感じかなと考えました。
PresetationalFormでInput.jsxやSelectBox.jsxのレイアウトを整え、ContainerFormでsubmit時の動作を定義しました。

ここで、選択肢をAPIで取得するSelectBoxが必要になりました。
ということでecosytemにApiSelectBox.jsxを増やしました。

• molecule　→　Input.jsx、SelectBox.jsx….
• organism　→　PresetationalForm.jsx
• ecosystem　→　ContainerForm.jsx、ApiSelectBox.jsx

このApiSelectBox.jsxはPresetationalForm.jsxでレイアウトを決める必要があるのですが、Atomic Componentではorganismがecosystemを参照していいのか明言されていません。

個人的には、orgnismがecosystemを参照してしまうとコンポーネントライブラリで使いにくくなってしまうのでダメだなと思っています。
となると、APIのコールをContainerForm.jsxで実施し、取得したデータをSelectBox.jsxにpropsで渡す案になりますが、APIのコールが何個もある場合どんどんカオスになってしまいます。できればAipSelectBox.jsxみたいな感じで、SelectBoxがAPIをコールしてoptionsを設定するのが理想だと思います。

この件については答えが見つかってないのですが、もうPresentationalForm.jsxを破棄し、ContainerForm.jsxでレイアウトを定義するのがいいかなと思っています。。。
正直Formに関してはAtomic Componentと相性が悪いと感じているのと、Formのレイアウトはコンポーネントライブラリになくてもいいかなって思うので、Formはecosystemにまとめて定義することにしました。

URLパラメータはenvironmentが処理するのか

environmentがURLパラメータの値を取得し、ecosystemにpropsで渡すのか、ecosystemがURLパラメータを取得するのか。。。
ここも解説記事では言及されていないのですが、URLパラメータはenvironmentが取得するのがいいと思います。
単純にenvironmentが仕事なさすぎというのもありますが、URLパラメータは画面に紐付いていると思えばenvironmentが自然だと判断しました。

まとめ

上記であげたように、Atomic Componentsを実践してみても悩む部分がありました。
個人的には、atom＋molecule＋organismは流用性が高いコンポーネントをまとめるpartsという層にしてしまうのが楽かなぁとぼんやり思っています。
そして、流用性が低いものはレイアウトも含めてecosystemに定義して、流用できそうなものをpartsに切り出していく。

まだまだ正解が見えていないですが、次回はatom＋molecule+organismの切り分けはゆるく捉えてやってみます。