AtomicDesignのチョベリファなところ

React × Redux × AtomicDesign の組み合わせで開発をはじめて、2 年近く経ちました。

最初は『AtomicDesign 最強！なんでみんな使わないの？』みたいに思っていたのですが、最近は『あれ、これ AtomicDesign じゃ対応できなくね…？』という部分も出てきました。

備忘録がてら、書き残していこうと思います。

アプリケーションの複雑度に比例して、pages がチョベリファになる

誤字じゃないです、超ベリーファットの略です。

Redux × React の接続は、container でのみ行われるべきだと Redux の公式サイトに書かれていますが、この考え方自体はとても素晴らしいと思います。

問題は、Redux × AtomicDesign の部分で、Store のデータを受け取る箇所が container のみであり、Redux 的には pages に限られてしまうということです。

ということは、api でのやり取りなどが増えるにつれ、container が肥大化していくのは、言うまでもありません。

なぜこの問題が起きるかと言うと、pages は、文字通り url と 1 対 1 で作成されるため、持つべき機能が大きくなりすぎるのです。

ここに form などを追加しようものならば、もうもうもう、とんでもないコードになってしまうのは明白です。

一応回避方法としては、HOC を通すなどがありますが、焼け石に水。

pages には onClick なんちゃらやら onChange うんちゃら、ライフサイクルメソッドの大乱立状態になってしまいます。