bulletproof-react を再読、気になった点まとめ
bulletproof-reactとは
Reactアーキテクチャのベストプラクティスを目指した作られたリポジトリです。
記事を書こうと思った背景
2年以上前、新規でReact開発を行う際にこのリポジトリを参考にし、大変助けられた記憶があります。
最近、Reactを新たに始めた方に「Reactのベストプラクティス」としてこのリポジトリを紹介した際、app router対応版が追加されているなど内容が更新されていることに気付きました。
久しぶりに内容を再読したところ、8割方は同意できるもののいくつか気になる点がありました。そのため、初学者にそのまま勧めづらいと感じました。この記事では、再読して感じた個人的な疑問点や突っ込みどころを整理して紹介していきます。
冒頭に関して
ここに関しては100%同意できる内容ばかりです
It is also very flexible, you can write React applications in any way you like, but that flexibility comes with a cost. Since there is no pre-defined architecture that developers can follow, it often leads to a messy, inconsistent, and over-complicated codebase.
自由で柔軟な点が魅力ではあるものの、それ故の辛みや不都合はその通りと思います。
The goal here is to serve as a collection of resources and best practices when developing React applications
だからこそ、ベストプラクティスを定義して、開発の指針になるリポジトリの存在は非常に助かります。
各ドキュメントに関して
Project Standards
概ね同意の内容ですが、今から新規開発をするのであれば、Biomeの導入を検討しても良いと思います。
個人的にはデメリットを上回るメリットがあると感じてます。
- メリット
- 設定が楽
- 実行が圧倒的に速い
- 勢いがあり将来性に期待できる
- デメリット
- 機能的に足りてない（Eslintでできることができない）
- 実用していて困るバグが少しある
活用する他のライブラリとの相性など次第では導入の候補に挙げて良いと思います。
Project Structure
従来から結構更新された箇所と思います。
In the past, it was recommended to use barrel files to export all the files from a feature. However, it can cause issues for Vite to do tree shaking and can lead to performance issues. Therefore, it is recommended to import the files directly.
バレルファイルはBiomeでも非推奨になっていましたが、かつては推奨される方法だったので更新がかかっていることが分かります。
また、importの制限を設ける点に関しては同意します。
一方で、App Routerのディレクトリ戦略に関しては疑問を覚えます。
src
|
+-- app # application layer containing:
| | # this folder might differ based on the meta framework used
| +-- routes # application routes / can also be pages
| +-- app.tsx # main application component
| +-- provider.tsx # application provider that wraps the entire application with different global providers - this might also differ based on meta framework used
| +-- router.tsx # application router configuration
+-- components # shared components used across the entire application
|
+-- features # feature based modules
|
+-- hooks # shared hooks used across the entire application
Pages Routerであればこれで良い思いますが、App Routerではapp以下にコロケーションする方が個人的には良いと考えてます。
src
|
+-- app
| +-- _components
| +-- user
| | +-- _components
| | +-- _hooks
| | +-- page.tsx
App Routerだと、page.tsxのみがルーティング対象になります。
また、ディレクトリの先頭に"_"を付与するとルーティング対象外にできます。
上記のような構成にすることで、全体で活用するコンポーネントと機能間で活用するコンポーネントが明示的になり、またよりコロケーションを実現できています。
Components And Styling
記載内容には概ね同意です。
コンポーネントライブラリの箇所、Mantineが新たに追加されたように見えます。
Chakra UIは使ったことありませんが、AntDやMUIと比べるとMantineはかなり使いやすいためお勧めです。
AntDの以下の記載ですが、
it might be a bit difficult to change the styles in order to adapt them to a custom design
bit difficultではなく、かなりしんどいです。
ハック的な感じでスタイルを書き換える必要があります。
API Layer
特になし
State Management
状態管理ライブラリ
ここで詳細の記載は控えますが、それぞれ特徴が結構違うので、解説ある方が良いと思いました。
個人的には大体のアプリケーションでグローバルステートは多用すべきでないという前提から、シンプルで開発も止まってないJotaiをお勧めします。
状態管理の多様をおすすめしない理由としては、Performanceの箇所にも記載されていますが、バグやパフォーマンス劣化の温床になりやすく、かつ多くの場合は使う必要がない（代替手段がある）からです。
Important to remember, context is often used as the "golden tool" for props drilling, whereas in many scenarios you may satisfy your needs by lifting the state up or a proper composition of components. Do not rush with context and global state.
Form State
MantineだとFormライブラリを内蔵しています。
Formライブラリとコンポーネントライブラリの噛み合わせを気にすることなく使える、というのもMantineの魅力です。
ただ、App Routerでこの辺りのベストプラクティスは変わりつつあるので、注視が必要です。
URL State
クエリパラメータの管理に関しては、以下の評判が良く、非常に使いやすそうに思います。
Testing
Vitestを紹介しているところは更新されたのを感じます。
Storybookでのテストも勢いがあるので、紹介すべきと感じました。
また、Chromaticなどのビジュアルリグレッションにも言及が必要と思います。
Error Handling
API Layerでreact-queryやapollo-clientの紹介があったので、それらを使ったエラーハンドリングに関しても記載があった方がベターだと思いました。
Security
特になし
Performance
記載内容には同意ですが、RSCやNext.jsの機能の記述は必要と思いました。
Deployment
記述がほぼありません。
Next.jsのデプロイ先としてはVercelでないと苦労する、などの記述は欲しいところ。
Additional Resources
リンク先追えてないですが、Next.jsやRemixの補足は必要に感じます。
まとめ
改めて読み直しましたが、Reactのベストプラクティスとして依然として有用なリポジトリだとは思います。
ただし、Next.jsやRemixに関する記載がほとんどない点に物足りなさを感じました。
その辺りは以下などで別途学ぶ必要があると思います。
Discussion