Closed18

Next.js+AtomicDesignのソース構成検討

himihimi

Next.jsでAtomicDesignを採用した場合のソース構成(ディレクトリ構成)のベストプラクティスが知りたい
が、探しても見つからない
おそらく「作るものによって変わる」ということなのだろうが、初めに何かしらの指標は欲しい

himihimi

間違いなく意識しておいた方が良いことは、
Atomic Designはフロントエンドのコンポーネント設計思想のように語られることもあるが、あくまでもデザインの設計思想
ということ
そっくりそのままNextやらReactやらに当てはめようとすると崩壊しそうなので、これは頭に入れながら検討するべき

himihimi

https://qiita.com/seya/items/8814e905693f00cdade2

  • コンポーネント化する目的はあくまでエンジニアの生産性向上のため、概念としての綺麗さと実装のしやすさがコンフリクトすることは往々にして起こります。
  • 原則としてコンポーネントは一つのことに責任を持つべきです。
  • 「子コンポーネントは親コンポーネントの"レイアウトのスタイル"を知ってはならない」
  • 「親コンポーネントは子コンポーネントの"見た目のスタイル"を知ってはならない」
  • 「原則スタイルはコンポーネントに閉じたものにする。可変にする必要・メリットが出てきた時に可変にする」YAGNIの精神で行きましょう。
  • 基本的にコンポーネントは"Containerコンポーネント"と"Presentationalコンポーネント"に分けて考えましょう。
  • 状態がコンポーネントに閉じている」場合はむしろそのコンポーネントで管理した方が楽になるでしょう。状態は必ずしも一箇所に全て集めなければならない訳ではない。
  • 3度目の法則
    タイトルは 「リファクタリング(Martin Fowlerの本)」 からパクってきました。概念上はAtomに分解できなくはないけど、1箇所でしか使われないUIパーツ、あると思います。これはデザインシステムをどう作って行きたいかの方針にもよるんですが、原則コンポーネント化の目的は再利用性を高めることです。

なので、そもそも再利用の必要性がないものに関してはコンポーネントとして切り出さないほうが結果として無駄なファイルが減らせて良いと思います。

ここで提案したいのが 3度目の法則。要は3回出現したら単一のコンポーネントとして切り出す、というルールを設けると意思決定がスムーズかと思います。
好みによっては 3回でなく2回でもいいかもしれません。

himihimi

https://zenn.dev/takepepe/articles/6978c067faab9e7d33c2

  • 関心範囲の広い横断的コンポーネントと関心範囲の狭い限定的コンポーネントを意識するべき
  • コンポーネントは、はじめは限定的コンテキストで実装するべきでしょう。共通利用される頃合いに、リファクタリングすれば十分です。
  • なぜ初めから横断的コンポーネントにできないのか
    フロントエンド実装は、デザイン成果物に依存しています。「デザインが全て出来上がっているから作ってお終い」ではない事がほとんどです。これは「締め切りまでにデザインが有った無かった」の話ではありません。サービスが成長するとともに、新しいコンポーネントが増えていくのは、デザイナーからしても予測可能なものですから。

限定的コンポーネントであったものが、サービスの成長に伴い横断的なものに昇華していく工程は不可避。つまり、継続的リファクタリングは不可避であるということです。モジュールシステムや静的型付けは、この様なリファクタリングを最大限サポートしてくれるでしょう。

seyaさんのQiitaの記事とは作り方のアプローチが違う
seyaさん:まずはコンポーネントとして切り出さず、「3度目の法則」によりコンポーネント切り出しの必要性が感じられたときに切り出す → 横断的コンポーネントしか生まれない

himihimi

https://simple-it-life.com/2020/12/24/component-design/#説明-1

  • MoleculesとOrganismsのどちらに含めて良いかわからない
    Organismsが独立して存在できるコンポーネントかどうか
    例えば「広告バナー」や「コメント投稿フォーム」はどのページにもそのまま配置できるということからOrganismsと判断します
    それに対して「シェアボタンリスト(Twitter, はてブなど)」や「投稿リアクション(いいねやコメント数など)」は複数のコンポーネントの組み合わせではありますが、それが独立して機能するかでいうとそうではなく、対象の記事があって初めてその記事に対する機能となるため、独立しているとは言えません

再利用性を求めるコンポーネント、求めないコンポーネントの分離(page,templateは求めない?)

himihimi

実際にNuxtでAtomicDesignを取り入れて開発した記録
templateは無くした独自設計
https://mya-ake.com/posts/component-design-based-on-atomic-design/
https://mya-ake.com/slides/atomic-design-for-component-design#22

Atomic Componentsについて
https://slides.com/kahirokunn/atomic-design-10
https://qiita.com/kahirokunn/items/b599d2cf04d2580c412c
https://bcu30.jp/2019/talk/okina-kahiro/

この辺が今の自分の悩みの答えかも…
結局AtomicDesignをWebアプリ制作にそのまま当てはめると色々不都合が出てくるのは当然のこと

himihimi

一旦整理

Next.js(React)におけるコンポーネント設計のベストプラクティスを知りたい



そもそもコンポーネント指向の目的って?

  1. メンテナンス性の担保
  2. 責任・役割の分離
  3. 再利用性

https://mya-ake.com/slides/atomic-design-for-component-design#22


コンポーネント設計する際心がけたいこと
https://qiita.com/seya/items/8814e905693f00cdade2
https://zenn.dev/takepepe/articles/6978c067faab9e7d33c2


AtomicDesignがデファクトスタンダート
https://simple-it-life.com/2020/12/24/component-design/
https://qiita.com/ysd_marrrr/items/e2b4eee15fa2fbaf00ac
https://speakerdeck.com/nrslib/vue-dot-js-and-atomic-design-guideline-for-components-division
https://qiita.com/empitsu88/items/f02513fa669a2ce0cd28




Atomic Designはフロントエンドのコンポーネント設計思想のように語られることもあるが、あくまでもデザインの設計思想


  • Webアプリの設計にそのまま取り込んでも色々不都合が出てくるのは当然

https://bcu30.jp/2019/talk/okina-kahiro/


  • この問題を抱えているのは世界的企業も同じ
    みんな独自の構造・仕組みを考えている

https://logmi.jp/tech/articles/300657


  • 実際に独自ルールを組み込んだAtomicDesignで開発した記録

https://mya-ake.com/posts/component-design-based-on-atomic-design/
https://devblog.thebase.in/entry/2019/11/27/110000


  • AtomicDesignの考え方をWebアプリ開発に向けて派生させたAtomicComponentsというものもある

https://slides.com/kahirokunn/atomic-design-10
https://qiita.com/kahirokunn/items/b599d2cf04d2580c412c


ここまででわかったこと


  • ベストプラクティスが存在しないことはわかっていたが想像以上に根深いテーマだった
  • 誰もが納得する結論は見つからなそうだけど自分なりの結論は出したい
このスクラップは2021/02/28にクローズされました