Reactのディレクトリ構造パターン例

• 数人のエンジニアしかいない小さなスタートアップ、スピードの速い環境

• PMFしていないため、捨てる可能性・変更する可能性がある

ディレクトリ構造と方針

Reactベストプラクティスの宝庫！「bulletproof-react」が勉強になりすぎる件

Reactアプリケーションのアーキテクチャの一例として公開されているGitHubリポジトリ「bulletproof-react」が大変勉強になるので、私自身の見解を交えつつシェアします。 まずはプロジェクトごとにバラつきがちなディレクトリ構造について。 bulletproof-reactでは、Reactに関するソースコードは srcディレクトリ以下に格納されています。逆に言えば、ルートディレクトリに componentsや utils といったディレクトリはありません。 たとえば Create Next Appで作成されるアプリケーションは、デフォルトではルートディレクトリに pagesといったソースコードのディレクトリが並びますから、 src 以下に入れるのは本リポジトリが意図的に行っているディレクトリ構造といえます。 実プロジェクトのルートには、マークダウンで書かれたドキュメント群（ docs）や、GitHub Actions等のCI設定（.github）、もしコンテナベースで扱っているアプリケーションであればDockerの設定（ docker）などが混在するでしょうから、ルートレベルに直接 components などを配置するとアプリケーションのソースコードとそうでないものが同一の階層に混在してしまいます。 単純に紛らわしいだけでなく、たとえばCI設定を書くときにもソースコードは src 以下に統一しておいたほうが適用する範囲を明示しやすくて便利です。 本リポジトリにおけるディレクトリ構造で面白いなと感じた点は、 features というディレクトリです。 src | +-- assets # assets folder can contain all the static files such as images, fonts, etc.

https://zenn.dev/meijin/articles/bulletproof-react-is-best-architecture

React+TSプロジェクトで便利だったLint/Format設定紹介

こんにちは、よしこです。 この記事は 2020年に立ち上げたWebフロントエンド構成の振り返り の「linter/formatter」項の詳細記事です。単体でも読めますが、よければ元記事もあわせてどうぞ！ この記事では、今わたしが 株式会社ナレッジワーク というスタートアップで開発・運用しているプロジェクトにおいて便利だったLint/Format関連の設定についてご紹介していきます。 ...

https://zenn.dev/yoshiko/articles/0994f518015c04

eslint-plugin-strict-dependencies

ESlint plugin to define custom module dependency rules. NOTE: eslint-plugin-strict-dependencies uses tsconfig, tsconfig.json must be present. npm install eslint-plugin-strict-dependencies --save-dev strict-dependencies module: string (Glob or Forward matching string) allowReferenceFrom: string[] (Glob or Forward matching string)Paths of files where target module imports are allowed.

https://www.npmjs.com/package/eslint-plugin-strict-dependencies

ディレクトリ

ファイル構成 - React

React はファイルをどのようにフォルダ分けするかについての意見を持っていません。とはいえ、あなたが検討したいかもしれないエコシステム内でよく用いられる共通の方法があります。 機能ないしルート別にグループ化する プロジェクトを構成する一般的な方法の 1 つは、CSS や JS やテストをまとめて、機能別ないしルート別のフォルダにグループ化するというものです。 common/ Avatar.js Avatar.css APIUtils.js APIUtils.test.js feed/ index.js Feed.js Feed.css FeedStory.js FeedStory.test.js FeedAPI.js profile/ index.js Profile.js ProfileHeader.js ProfileHeader.css ProfileAPI.js ここでの「機能」の定義は普遍的なものではないので、粒度の選択はあなた次第です。トップレベルのフォルダの名前が思いつかない場合は、ユーザに「この製品の主な構成部品は何か」と聞いてみて、ユーザの思考モデルを青写真として使いましょう。 ファイルタイプ別にグループ化する プロジェクトを構築する別の人気の方法は、例えば以下のようにして類似ファイルをグループ分けするというものです。 api/ APIUtils.js APIUtils.test.js ProfileAPI.js UserAPI.js components/ Avatar.js Avatar.css Feed.js Feed.css FeedStory.js FeedStory.test.js Profile.js ProfileHeader.js ProfileHeader.css 人によってはこの方法をさらに推し進め、コンポーネントをアプリケーション内の役割に応じてフォルダ分けすることを好みます。例として、 Atomic Design はこのような原則の下に作られたデザインの方法論です。ただこのような方法論は、従わなければならない厳格なルールとして扱うよりも、役に立つ見本として扱う方が多くの場合生産的であるということを忘れないでください。 ネストのしすぎを避ける 深くネストされた JavaScript プロジェクトには様々な痛みを伴います。相対パスを使ったインポートが面倒になりますし、ファイルが移動したときにそれらを更新するのも大変です。よほど強い理由があって深いファルダ構造を使う場合を除き、1 つのプロジェクト内では 3 段か 4 段程度のフォルダ階層に留めることを考慮してください。もちろんこれはお勧めにすぎず、あなたのプロジェクトには当てはまらないかもしれません。 考えすぎない まだプロジェクトを始めたばかりなら、ファイル構成を決めるのに 5 分以上かけない ようにしましょう。上述の方法の 1 つを選ぶか、自分自身の方法を考えて、コードを書き始めましょう！ おそらく実際のコードをいくらか書けば、なんにせよ考え直したくなる可能性が高いでしょう。 もしも完全に詰まった場合は、すべて 1 フォルダに入れるところから始めましょう。そのうち十分に数が増えれば、いくつかのファイルを分離したくなってくるでしょう。そのころには、どのファイルを一緒に編集している頻度が高いのか、十分わかるようになっているでしょう。一般的には、よく一緒に変更するファイルを近くに置いておくのは良いアイディアです。この原則は、「コロケーション」と呼ばれます。 プロジェクトが大きくなるにつれ、実際にはしばしば上記両方の方法が組み合わされて使用されます。ですので、「正しい」方法を最初から選択することはさほど重要ではありません。

https://ja.reactjs.org/docs/faq-structure.html

src

src
|
+-- components        # 共通コンポーネント
|
+-- constants         # URLなどのアプリケーション全体
|
+-- features          # feature based modules
|
+-- hooks             # 汎用的なhooks
|
+-- lib               # NPMライブラリに依存する汎用的な関数. wrapperなど
|
+-- pages             # Next.jsを採用したため. route
|
+-- routes            # routes configuration
|
+-- scheme            # zod schemeなど
|
+-- styles            # global style, colorなど。chakraのthemeなども
|
+-- types             # 共通のtype.d.tsなどをここに
|
+-- utils             # 汎用的なユーティリティ関数.

• 全体管理：Context

• 部分管理：Recoil

features

src/features/awesome-feature
|
+-- api         # APIアクセスする主にPromise関数
|
+-- hooks       # feature依存hooks: apiファイルやformのstate管理など
|
+-- state       # 機能に依存するstate(Recoil)
|
+-- (etc)       # その他、機能に関するものすべて. converterなど

components

src/components
|
+-- context                  # 全体store. Context
|
+-- features/awesome-feature # 機能依存のComponents: 主にForm.tsxなどでfeaturesのhooksを呼び出す
|
+-- pages                    # Next.js(~v12)でpageコンポーネントを分割するため
|
+-- ui                       # UIパーツを配置。基本的にstorybookで構築できるようなプリミティブな値を引数にする。

components/ui

src/components/ui
|
+-- (parts name)       # 各UIパーツ
|
+-- layouts            # FooterやHeaderなどパーツを組み合わせたもの

// .eslintrc.json
{
	"strict-dependencies/strict-dependencies": [
      "error",
      [
        /**
         * Example:
         * Limit the dependencies in the following directions
         * pages -> components/page -> components/ui
         */
        {
          "module": "@/components/page",
          "allowReferenceFrom": ["@/pages"],
          "allowSameModule": false
        },
        {
          "module": "@/components/ui",
          "allowReferenceFrom": ["@/components/pages", "@/components/features"],
          "allowSameModule": false
        },

        /**
         * example:
         * Disallow to import `next/router` directly. it should always be imported using `libs/router.ts`.
         */
        {
          "module": "next/router",
          "allowReferenceFrom": ["src/lib/router.ts"],
          "allowSameModule": false
        },
        {
          "module": "@/*",
          "allowReferenceFrom": ["src/*"],
          "allowSameModule": false
        }
      ],
      // options
      {
        "resolveRelativeImport": false
      }
    ]
}

// tsconfig.json
{
	...
  "compilerOptions": {
    "baseUrl": "./",
    "paths": {
      "@/*": ["src/*"]
    }
  }
	...
}