Reactアプリケーションの構造化 – Atomic Designの原則
僕がプログラミングを始めたばかりの頃は、
デザインパターンやファイル構造といった抽象的なプログラミングの概念がどのようなもので、
なぜそれが重要なのか、まったくわかりませんでした。
しかし、今となってではプロジェクトの構造やデザインパターンに従うことはとても大切だと思っています。
そしてAtomic Designの原則は、問題解決をより全体的にとらえることで、
私のコーディングの道のりを変えてくれました。
アトミックデザインとは、ユーザーインターフェースをより小さなシンプルな要素に分割するというコンセプトで、
最終的にはメンテナンス性に優れた一貫性のあるUIを作ることができます。
なぜアトミックデザインなのか？
私が初めてこの方法論を使い始めたのは、大規模なReactシングルページアプリケーション（SPA）の場合でした。
多くのカスタムコンポーネントを作成する必要がありましたが、
現在のCSSフレームワークやライブラリを見ても解決策は見つかりませんでした。
そのため、HTML要素とカスタムCSSを使ってコンポーネントを作成しなければなりませんでした。
すべてのコンポーネントを1カ所に集めるというコンセプトは非常に興味深く、
実際に開発期間の短縮にもつながりました。
ブラッド・フロスト氏は、この化学の用語を借りて、アトミックデザインのコンセプトを導入し、
それをUIコンポーネントに活用することは理にかなっていると思います。
Webサイトの構成要素はHTMLの要素であり、ちょうど原子のようにこれらの要素が組み合わされて複雑なページを形成しています。
開発者によってデザインされた各ページは、化学で学ぶ分子や生物と同じように、小さな構成要素に分解することができます。
Atoms, Molecules, Organisms, Templates, and Pagesに分ける
アトミックデザインとは、atoms, molecules, organisms, templates, それから pagesが同時に作用して、効果的なインターフェースデザインシステムを構築することです。
アトム(atoms)
アトム(原子)とは、ボタン、タイトル、入力、テキストなど、可能な限り小さなコンポーネントのことで、
ボタン、タイトル、入力、テキストなど、可能な限り小さなコンポーネントのことで、
インターフェイスのアトムは、コンポーネントの基礎となる構成要素であり、これ以上分解すると機能しなくなってしまいます。
モレキュール(molecule)
モレキュール(分子)はその名の通り、2つ以上の原子で構成されており、
分子はユニットとして一緒に機能するUI要素の比較的単純なグループです。
例えば、HTMLのテキスト入力、ラベル、エラーメッセージで構成されるテキストフィールドや、
HTMLのテキスト入力とボタンで構成される検索ボックスなどがあります。
オーガニズム(organism)
オーガニズム(organism)は、
モレキュール(molecule)やアトム(atoms)や、
他のオーガニズム(organism)のグループで構成される、
比較的複雑なUIコンポーネントです。
これらのオーガニズム(organism)は、
インターフェイスの明確なセクションを形成します。
これらの小さなコンポーネントを組み合わせることで、
アプリケーションのユーザーインターフェースが構成されます。
前述のコンポーネントを使用して、想像上のコードベースのための開始フォルダ構造を具体化することができます。
フォルダの位置はコードベースによって異なりますが、実装する前にチームで話し合うことが重要です。
上のスクリーンショットでは、フロントエンドで使用するすべてのコンポーネントを格納するためにComponentsフォルダを用意し、
小さなデザインコンポーネントをページレベルの構造から分離するためにUIフォルダを用意しました。
メリット
コンポーネントは、アプリケーションとは別に開発し、
スタイルガイドのようなツール上でテストして確認してから、アプリケーションにインポートすることができます。
これは、フロントエンドの開発を始めるにあたり、
バックエンドのアプリケーションロジックに過度に依存することがないということでもあります。
一連のパターンが確立されると、より迅速な構築プロセスが可能になり、
デザインに変更を加える必要がある場合にも柔軟に対応できます。
また、既存のコンポーネントを多く再利用しているため、デザインの一貫性も高くなります。
また、このパターンでは、CSSが特定のコンポーネントに関連付けられているため、
CSSの管理が容易になります。
そのため、アプリケーションのアーキテクチャに応じて、
レンダリングされるコンポーネントで使用されるCSSのみをレンダリングする必要があります。
デメリット
コンポーネントが独立している場合、親コンテナのサイズを決定する方法がないため、
メディアクエリが少し難しくなります。
コンポーネントは自分の幅を知らないので、実際のページサイズの変更に応じてリサイズが行われます。
この問題を解決するには、コンポーネントを囲み、それに合わせてサイズを変更するレイアウトコンポーネントを導入する必要があります。
これらのレイアウトコンポーネントは、フレックス、グリッドなどのCSSレイアウトプロパティを実装します。
最後の仕上げ
現在、上のスクリーンショットでは、アプリがコンポーネントだけで存在していることがわかります。
必要なのは、これらのコンポーネントを更新するためにビジネスロジックを導入する信頼できる方法です。
私は、ビジネスロジックをビューから離しておくことは良い方法だと思います。
こうすることで、特にプロジェクトが拡大し始めたときに、コードの問題をデバッグするのが容易になります。
これを実現するには、さまざまなアプローチを採用する必要があります。
私は個人的に、高次コンポーネント（HOC）を使用し、特定のページへのプロップを使用してページに任意の状態を入力するのが好きです。
この状態は、アプリケーション内で共有される一連のAPIコールを指定できます。
他のソリューションとしては、render propsパターンやreact-hooksがあります。
これをもっと抽象的に説明すると、あなたのコンポーネントが下の画像のような同じ色とサイズの空のボトルだとして、
あなたは、それぞれのボトルに異なる色の液体を入れることにしました。
これは、異なるコンポーネントの状態を更新することに似ていますが、この場合、あなたの状態は液体であり、ボトルはあなたのコンポーネントです。
空のボトルにそれぞれ異なる色の液体を入れれば、より簡単な処理になりますし、何かの理由で色を変えて状態を更新する必要が生じたとしても、より簡単な処理になります。
しかし、ボトルの半分に赤い色の液体を入れておいて、途中で別の色の液体を入れたくなった場合、ちょっとした問題が発生します。
混ざらなかったらどうしよう？ 混ぜられなかったらどうしよう？ 元の色を消して別の色に変えなければならないのでは？
これはまさに、ビジネスロジックを実装したビューがある場合に起こるシナリオで、
将来的にコードをリファクタリングするのが難しくなり、
ビューの再利用も難しくなります。
私が思いついたのは以下の通りです。
Reactは独立していますが、1つのプロジェクト内でネストしたフォルダは最大でも3つか4つに留めることをお勧めします。
[st-minihukidashi fontawesome=”” fontsize=”” fontweight=”” bgcolor=”#FFB74D” color=”#fff” margin=”0 0 20px 0″ radius=”” add_boxstyle=””]この記事は下記の英語の記事を翻訳しながら要点だけ分かりやすくまとめたものです[/st-minihukidashi]
りょすけと申します。18歳からプログラミングをはじめ、今はフロントエンドでReactを書いたり、AIの勉強を頑張っています。off.tokyoでは、ハイテクやガジェット、それからプログラミングに関する情報まで、エンジニアに役立つ情報を日々発信しています！