【React&TypeScript入門】パッケージ構成意味のある分け方

PR
【React&TypeScript入門】アプリ開発!お困りごとの解決方針
この記事は約7分で読めます。
PR

PR
PR

PR
PR

アプリ開発直後のお困り事

パッケージ構成どうする問題

どうやって整理していったら良いかほんとに迷いどころ

考え方がものすごく分かれるため、調べれば調べるほど、分からなくなると思います

いろんな名前がついていてよくわからないので、もう調べるのやめましょう!

初めて作る場合やあまり詳しくない場合、ほかにも悩む部分が発生するため、
一旦雰囲気でやっていきましょう

今回はこの2つで紹介していきます!

  • Atomic デザインぽく作ってみる
  • 機能単位に分けて作ってみる

Atomic デザインぽく作ってみる

src/
├── atoms/                // (原子)最も小さなコンポーネント
│   ├── Button/
│   │   ├── Button.tsx    // Buttonコンポーネントの実装
│   │   ├── Button.css    // Buttonコンポーネントのスタイル
│   │   └── index.ts      // Buttonコンポーネントのエクスポート
│   ├── Input/
│   ├── Checkbox/
│   └── ...
├── molecules/            // (分子)複数のアトムを組み合わせたコンポーネント
│   ├── LoginForm/
│   ├── Navbar/
│   └── ...
├── organisms/            // (有機体)複数のアトムと分子を組み合わせたコンポーネント
│   ├── Header/
│   ├── Sidebar/
│   └── ...
├── templates/            // (表示ページを構成するレイアウト)ページの構造を定義するコンポーネント
│   ├── DefaultLayout/
│   ├── DashboardLayout/
│   └── ...
└── pages/                // (表示ページ)実際のページコンポーネント
    ├── Home/
    ├── About/
    └── ...
  • atoms
    • 限りなくどこにも依存しない、最小単位のコンポーネント
    • めったに直さないつもりで作る
  • molecules
    • 依存が発生する単位のコンポーネント
    • organismsより小さい単位のコンポーネント
  • organisms
    • 動きや表示等の機能仕様を含めて良いコンポーネント
  • templates
    • ページを構成するレイアウト
  • pages
    • 表示するページ

機能で分けて作ってみる

専用、専門、機能などの感じで切り分けていくスタイルで作っていきます。

ドメイン駆動設計(DDD)とかありますが、読みだしたら時間掛かるし切りがないと思っています。
この考えから来ていますが、(時間が掛かるため)完璧に踏襲しようとしていません。
良いと思った部分を組み合わせて考えてみました。
※ドメインとは、特定の分野や専門分野を指します。(ドメインで分離させるのは、関連性やわかりやすく良いですね)

src/
├── components/
│   ├── commons/     // 共通コンポーネント
│   │   ├── Button/
│   │   ├── Checkbox/
│   │   └── ...
│   └── domains/       // 機能固有のコンポーネント
│         └─── ...
├── infras/                  // インフラストラクチャ層
│   └─── ...
├── types/                  // 型定義
│   └─── ...
├── utils/                     // ユーティリティ関数
│   └─── ...
├── hooks/                 // カスタムフック
│   └─── ...
└── pages/                 // ページコンポーネント
  • components
    コンポーネントを配置するパッケージ
    • commons
      • 共通的なコンポーネント
      • このフォルダをボタンなどに更に細分化する
    • domains
      • 機能固有のコンポーネント
      • このフォルダを機能単位に更に細分化する
  • infras
    • インフラストラクチャ層のパッケージ
    • データベース接続や外部API連携など、アプリケーションの基盤となるインフラストラクチャに関連する処理を担当する
  • types
    • 型定義を配置するパッケージ
    • アプリケーション全体で使用される共通の型を定義
    • 機能内に収まる型は、domainsの中でも良いかもなと思ったりもするがここに入れておこうか
  • utils
    • ユーティリティ関数を配置するパッケージ
    • アプリケーション全体で共通のユーティリティ関数を定義して再利用する場合に使用
  • hooks
    • カスタムフックを定義するためのパッケージ
    • アプリケーションで共通のロジックを抽象化して再利用する場合に使用
    • 副作用系はここに切り出すと良さそう
  • pages
    • ページコンポーネントを配置するパッケージ

ESLintの導入方法

ESLintは必要です!
必ず知っていた方が良いです。
理由は、誰かが設定してくれることが多く、いざ自分で設定しようと思うと、あれ?どう設定するの?となりがちのため

  • eslintライブラリのインストール(typescriptの場合は、@typescript用をインストール)
  • .eslintrc.jsへの設定(下記のように初期設定がある)
    ※カスタムルールの追加も可能
    • no-unused-vars
      宣言されたが使用されていない変数を検出します。
    • semi
      行末のセミコロンの使用をチェックします。
    • no-undef
      未定義の変数の使用を検出します。
    • indent
      インデントの「スタイル(スペースまたはタブ)」と「サイズ」をチェックする

ビルドとExport方法

アプリを作るなら、これは知っておきましょう!

packge.jsonのscriptsに設定を追加する

{
  ・・・
  "scripts": {
    ・・・
    "dev": "next dev",
    "build": "next build",       ← 追加、または変更
    "export": "next export"  ← 追加、または変更
  },
  ・・・
}

下記コマンド実行でビルドしてexport(静的ファイルの出力)

設定しない場合、「/out」フォルダに出力されますが
next export -o」 または 「--output」 を追加で別フォルダに出力できます〜
例)next export -o public と書く/publicフォルダ出力

# npm の場合
npm run build
npm run export

# yarn の場合yarn build 
yarn export

# pnpm の場合pnpm build
pnpm export

※下記のようにbuildコマンドだけで一度に出力することもできます!

{
  ・・・
  "scripts": {
    ・・・
    "dev": "next dev",
    "build": "next build && next export"  ← 追加、または変更
  },
  ・・・
}

出力されたファイルをサーバーに置けばサイトの更新完了です

次に気になるポイント

SSRとSSGってどのように使わけたらよいのかを解説

ごあいさつ

こちらでフリーランスに関する記事や参考書、ツールの導入なども紹介しています。

PR
PR

コメント

タイトルとURLをコピーしました