なぜフロントエンドでatomic designが使われなくなったのか（私見）

なぜかというと依存方向が一定なフロントではatomic designは意味がないからだ

atomic designはバックエンドのレイヤードアーキテクチャのようなものだ

バックエンドのレイヤードアーキテクチャはDIPを用いることで依存関係が柔軟に変更できる環境下で依存方向を意識するのに役立っている

ではフロントではどうか

フロントにはDIP（依存性逆転の原則）はない（後述）

なので依存方向は常に「大きいコンポーネント」→「小さいコンポーネント」になる

さてここで考えたいが依存方向が常に一定の状況でレイヤードアーキテクチャが使われるだろうか？

いや、使われないだろう

なぜなら、依存方向が常に一定ならわざわざフォルダ構成やアーキテクチャでそれを示す必要がないからだ

この理屈はatomic designにも言える

おそらく、フロントの民たちはatomic designで「うおーフロントでもレイヤードアーキテクチャや！！！」ってなった後で「依存方向一定だし、atomic designの意味なくね？」ってなったんだと思われる

そうしたフロントの民の気づきの結果atomic designが使われなくなったのではないだろうか

なぜフロントにはDIP（依存性逆転の原則）がないのか

フロントにもDIはある

Contextがそれだ

筆者は宗教上の理由でReactしか書けないが、VueやAngularも分からなくないのでそっち側の文脈で言うならProvide / Injectとか@InjectableとかがDIだ

ではDIがあるのになぜDIPがないのか

それはメリットがないからだ

おそらくフロントでDIPをするならReactなどのUIライブラリやAPIにアクセスするコードなどをレイヤードアーキテクチャの上層（より依存されないところ）に持っていくだろう

さてここで考えてほしいのが、それって意味ある？ってことだ

本来DIPは変更容易性やテストの書きやすさに寄与するが、mswやjestで柔軟なモックができ、テスティングトロフィーでインテグレーションテストの有効性が唱えられてるフロントでDIPは本当に価値があるのだろうか

いや、ないだろう

APIへアクセスするためのコードはmswを使えばテストは容易だし、APIへアクセスするコードに変更があるときはまず間違いなくDOMに影響がある、仮にDOMに影響がないならその差分はAPIへアクセスするコード内で吸収されるべきだ

また、ReactなどのUIライブラリをDIPで依存関係の外に持って行くのは現実的にはまず不可能だ

仮にReactでDIPができたとしても、それをVueやAngularにも対応可能な形にする必要があるし、そこまでして変更を容易にしてもまず変更する機会がない

UIライブラリの変更とはそれに伴うアーキテクチャの変更がメリットなことがほとんどなのでDIPでその差分を吸収してしまっている時点で変更する機会が消える

というわけで、フロントでのDIPは意味がないのだ