はじめに
こんにちは。サーバーサイドエンジニアの mokuo です。
最近、ミニマムな React アプリを実装する機会がありました。
社内のメンバーにアドバイスをもらいながら、今（2024年前半） React アプリをミニマムに作るならこんな感じかな、という構成になった気がするので、ご紹介したいと思います。
実例の1つとして参考にしていただけますと、幸いです。
本文
📝 機能要件
社内の限られた CS メンバーのみが利用する、管理画面を開発しました。
バックエンドは Golang で実装される API サーバーで、認証機能以外だと、2つの機能のみで構成されるシンプルな Web アプリケーションになっています。 インフラやバックエンドについての詳細は、以下の記事を御覧ください。
⚒️ 採用したツール (npm モジュール)
| パッケージ名 | カテゴリ | 選定理由 |
|---|---|---|
| npm | パッケージ管理 | スマートバンクとしては、管理画面は yarn だがプロダクトサイトは npm なので、どちらも利用している。lock ファイルや速度など、npm と yarn の機能差が少なくなり、npm が選択されるケースが増えてきている印象。 |
| Vite | ビルドツール | create-react-app と vite を比較して、Vite を採用しました。 |
| Vitest | テスト | Jest と互換性があって書き方も変わらなそう |
| @testing-library/react | テスト | 評判が良く、最近採用されるケースが多そう |
| nock | テスト | http リクエストをモックするライブラリ |
| Biome | Linter, フォーマッター | ESLint + Prettier の代替として注目されている Linter とフォーマッタの機能を含んだツール。複数の依存ライブラリを入れる必要がなく、設定もシンプル。 |
| wouter | ルーター | Next.js, wouter, React Router, TanStack Router あたりが候補に上がった。今回は2ページしかないアプリケーションなので、最も軽量な wouter を選択。 |
| Amplify, Amplify UI | 認証 | 用意された React コンポーネントを利用することで、楽に認証画面を実装することができる。実際、工数をかけずに組み込むことができました。 |
| Material UI | UI | 既存の管理画面で使用されている React-Admin が内部で利用しているので、使い勝手を統一できる。個人的にも、使い慣れているライブラリである。 |
以下、Vite の選定理由について補足します。
- 他社事例
- Build Tools の2位が Vite
- (Retention) Vite: 98.4%
また、既存の管理画面でも Vite を利用しています。詳しくは以下の記事をご覧ください。
📁 ディレクトリ構成
.
├── node_modules
├── public
└── src
├── clients
├── components
└── pages
以下、☆ が付いているのが、独自に作成する(予定の)ディレクトリで、それ以外は npm create vite@latest コマンドが自動生成したディレクトリになっています。
node_modulespublic- 静的なファイル
src- ☆
clients- 外部への通信を行う API クライアントクラス
- infrastructures, repositories なども検討したが、他のディレクトリ名と同様に直感的な名前にした
- ☆
components- 共通コンポーネント
- ☆
pages- ページごとのコンポーネント
- ☆
基本的には pages の下に、ページ毎にディレクトリを切っています。そのページで使うコンポーネントはすべて同じディレクトリに含めるようにしていて、シンプルな構成になっています。
👨💻 プロトタイピングの実施
社内の既存の管理画面は React-Admin というフレームワークを使って実装されています。
今回も同じ管理画面ということで、React-Admin が候補に上がりましたが、以下の懸念点がありました。
- React-Admin 特有の知識が必要になる
- 今回の要件だと、React-Admin の機能をほとんど使わない
- 依存パッケージが大量に存在するので、バージョンアップ作業が大変になる
そこで、フレームワーク無しの React と、React-Admin の2パターンでプロトタイピングを実施して、比較をすることになりました。
結果として、以下の理由から、フレームワーク無しの React で実装することに決定しました。
また、Next.js, Remix 等のフルスタックフレームワークについても検討しましたが、今回は要件も少なく小さなアプリケーションであり、SSR も不要であり、too much であると判断しました。
🍩 おまけ
コンポーネント設計について
一時期は Atomic Design が流行っていたが、知り合いの Web フロントエンドエンジニアによると、今は教養として知っておくと良いくらいの立ち位置になっているようです。 現在は Atomic Design を参考にしつつ、各社・各チームが独自に工夫をしていて、デファクトスタンダードが存在していないイメージがあります。
手前味噌で恐縮ですが、Atomic Design については、私の前職のブログを載せておきます。
フロントエンドに DDD のエッセンスを取り入れてみたい
今回の要件には当てはまらないですが、ある程度複雑な SPA を開発するなら、DDD の概念を取り入れてみたいと思っています。
DDD 界隈では、推奨されるアーキテクチャがいくつか存在している認識です。 個人的には、レイヤードアーキテクチャやオニオンアーキテクチャくらいがちょうど良いと考えていて、フロントエンドにも以下のような構成で取り入れられないか、などと妄想しています。
- プレゼンテーション層
- コンポーネント
- アプリケーション（ユースケース）層
- カスタム hooks をユースケースとして捉えられないか？
- ドメイン層
- 関数型DDDの概念を取り入れて、JS の object と関数でドメイン層を実装する
- 参考
- インフラストラクチャ層
- API クライアント
おわりに
いかがでしたか。
規模の小さい React アプリケーションを実装する際など、技術選定の参考にしていただけますと、嬉しいです。
スマートバンクでは、エンジニアを募集しています。ご興味あれば、ぜひ以下のサイトもご覧ください！
