🦄

フロントエンドのコンポーネント設計において参考になる記事まとめ

2022/10/10に公開

背景

コンポーネント設計について調べてみると、「いつどういうコンポーネント設計をすればいいのか」が、なかなか答えをだすのが難しいです。今回は、その答えまでは導けないまでも、よりよりコンポーネント設計の一助になればと思い、自分がこれまで参考になったコンポーネント設計の記事を自分の所感つきでまとめました。自分がReactエンジニアなのでReactの記事で紹介しますが、vueなどの他のフロントエンドの世界でも通じるかと思います。

粒度で設計する

Atomic Design

Atomic Designは、そもそも、デザインシステムを前提としてコンポーネント設計です。https://atomicdesign.bradfrost.com/
デザイナーさん目線のコンポーネントの分類の方法で、フロントエンドエンジニア向けではありません。
これを採用するのは、UIの細かな調整によって、ユーザ体験に大きく影響するサービスで、デザイナー・エンジニア間で細かな連携が必要なときに導入することが多いと思います。

ぐぐると上に出てきて、わかりやすくて導入しやすそうなのですが、個人的に、『他に丁度いいやつないから、とりあえず入れてみよう!で痛い目見るコンポーネント設計ランキング』で一位です。

実際入れてみるとわかりますが、分類方法が人による、コンポーネントの分割が細かい(個人的には)などのそのままコンポーネント設計にするには苦しいところがあります。Atomic Designを運用するルールを追加作って行くのが通常かとおもいます。
個人的には、「デザイナーさんと共通言語」目的がないと、運用するのだけで疲れるので、あまりいれないです。

参考

https://note.com/tabelog_frontend/n/n4b8bcb44294c

https://mya-ake.com/posts/component-design-based-on-atomic-design/

https://zenn.dev/takepepe/articles/jest-custom-matcher-for-atomic-design

https://qiita.com/teradonburi/items/6828635d2e70dba6637d

https://buildersbox.corp-sansan.com/entry/2022/01/06/110000

Atomic Design カスタマイズ運用

Atomic Designを使ってみると、そのままの開発体制にフィットしなかったり、使いづらかったりします。Atomic Designをカスタマイズして運用するところも多いようです。

参考

https://note.com/tabelog_frontend/n/n07b4077f5cf3

https://devblog.thebase.in/entry/2019/11/27/110000

関心事で設計する

modelやfeature、domainなどいろんな表現がありますが、ひとくくりで関心事で区切っているとしてまとめています。

よしこさんのコンポーネント設計

page + models(関心事あるコンポーネント) + ui(関心事ないコンポーネント) + functional(UIがないコンポーネント) という切り方です。シンプルで非常にわかりやすいので、小さいなプロジェクトで使い回しがいいと思います。ただ大きなプロジェクトでやろうとすると、シンプルすぎて、uiの配下やmodels配下などは散らばりそうなので、そのへんはもうひと分類追加する必要がありそうです。

参考

https://zenn.dev/yoshiko/articles/99f8047555f700

bulletproof-reactの分類方法

コンポーネント設計というよりプロジェクト全体に渡る切り方です。基本的な考え方は、「関心事(feature)が同じ要素は、近くにあるほうがいい」です。コンポーネントだろうがAPIだろうが関心事で分類するので、そもそもコンポーネント設計という考え方をぶち破ってくれるいい例だなと思います。ただ、一つのページに関心事が複数あったり、ある特定の関心事が複数の箇所に出だしたりすると、featuresをまたいだ関心事の使いまわしが絶望的に悪いので、関心事が分散していないかを気にする必要はあると思います。

参考

https://github.com/alan2207/bulletproof-react/tree/master/src/features

BCD Design

ググるとドワンゴさんの記事しか出てこなかったので、どこに出典があるのかわからなかったです。ドワンゴさんがつくったコンポーネント設計かもしれません。関心事と別に状況(Case)という考え方を持ち込み、名前の付け方やコンポーネントの分類も含めて考える量が減ります。個人的に、いままで見た中で一番良さそうだなと思いました。

参考

https://qiita.com/misuken/items/19f9f603ab165e228fe1
https://zenn.dev/misuken/articles/41ec53bb376e55

まとめ

以上、自分がすごく参考になると思った記事を挙げさせてもらいました。
まとめてみて思ったのは、

  • 開発体制(デザイナーさんとエンジニアの協業具合)
  • 関心事のページへの分散
  • プロジェクトのサイズ感

このあたりが、コンポーネント設計をする上で重要な観点なのかなと思いました。
他にもこんなコンポーネント設計もあるよ などあれば教えてもらえると嬉しいです。
ご拝読ありがとうございました。

Discussion