himi

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

himi

参考になりそうな記事

himi

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

himi

コンポーネント指向の目的

再利用性を高める
デザインと技術の共同作業をしやすくする

メンテナンス性の担保

himi

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

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

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

himi

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

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

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

himi

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

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