Next.js,Reactによる開発効率を上げるための環境構築

なぜこの記事を書いたのか

以下の理由で作成しています。

• 技術ノウハウの発信場所
• Next.jsのアウトプット

スキルのキャッチアップの中で、個人での開発の知見により救われたことが多くありました。そこで、自分でも他のエンジニアの方の役に立とうと思い、この記事を書きました。

フロントエンドの全体像の続き

以下の記事ではフロントエンド全体像について書きました。かなり好評だったので、
そこから開発効率を上げるために特化した記事を書こうと思いこの記事を書きました。

検証で使ったソースコード

• Next.jsの環境構築

TypeScript

Typescriptの導入することで以下のメリットがあります。

• 型安全性の向上

1. エラーの早期発見(コンパイル時に型エラーを検出)
2. コードの予測性向上(明確な型定義により、コードの意図を理解しやすくなり、予期しない挙動を防げる。)
3. リファクタリングがしやすくなる(型情報に寄って、IDEのサポートを受けながら安全にコードを変更できる。)

• TypeScriptを導入する状況

1. 大規模プロジェクトやチーム開発
2. 保守性を重視したプロジェクト
3. 型の恩恵を受けやすい複雑なデータ構造やAPIを扱う時

状態管理

ここでは採用していないがContextAPIがいいと思います。
他のメンバーとチームで開発をする上で、共通化できるもには共通化したいと思います。
Reduxは学習コストがかかるので、個人的にはおすすめしないです。

コンポーネント設計

AtomicDesignが1番有名です。

最近では、featuresやsharedなどを使う現場も出てきたみたいです。

• features
  特定の機能やページに特化したコンポーネントやロジックを置くためのディレクトリです。

• shared
  アプリケーション全体で使い回すコンポーネントやロジックをまとめるためのディレクトリです。

ex)
shared/components/Buttonアプリ全体で使われるボタンコンポーネント shared/components/Modal アプリ内で使用するモーダルウィンドウ

StoryBook

UIのカタログです。UIをブラウザ上でカタログ化して、ブラウザで可視化できるものです。

Webエンジニア(フロントエンジニア)とWebデザイナー同士で、フロント部分の開発をする際に、お互いに、コンポーネントなどで相違がないかを確認し、共有できます。

StoryBookのおかげで、デザイナーとフロントエンジニアとのコミュニケーションコストを抑えることができ、デザインと実装の間での反復がスムーズになり、プロジェクト全体の効率が向上します。以下の特徴を知っておいてください。

1.視覚的な共有
2.デザインの統一
3.ドキュメントの機能
4.コンポーネントの再利用性

・自分の記事です。

あとSmartHRでもStoryBookは公開しています。

StoryBook導入の観点

Atomic DesignでいうとこのAtoms(UIの変更があまりないところ)だけカタログ化するといいと思います。
UIの変更が少ないない箇所をカタログ化していくといいと思います。

ただStoryBookを作るのはハードルが高くて工数もかかるのが注意です。
実際作ってみたのですが難しいです。

OpenAPIを用いたスキーマ駆動開発(Swagger)

API の仕様を記述したスキーマを中心に開発を進める手法です。

Swaggerの観点

バックエンドとフロントエンドで分けている開発現場で有効です。
フロントエンドかバックエンドのAPIができるまでもしくは
毎回確認しなければ開発か進まない課題がありました。

これをAPIのエンドポイントで可視化して開発効率を上げる取り組みをしました。
これがSwaggerです。

・自分の記事です。

Swagger自動生成できるフレームワーク

FastAPI(Pythonのフレームワーク)、Nest.jsには自動生成機能があります。
自動生成できるフレームワークも出てきています。

テスト(Jestなど)を導入する観点

UIの変更がない箇所に導入するといいと思います。
重要な機能を中心にやっていくのでいいです。テストカバレッジはC1でいいと思います。C2までは不要かと思います。やりすぎてしまうと工数がかかってしまうからです。

・自分の記事です。

E2Eテストの観点

あらゆる画面や処理でかなり重いテストになり、時間がかかり工数がかかってしまいます。
これを解決するためにCypressを導入すれはいいと思います。

Cypress導入の観点

無料でE2Eの自動テストフレームワークのCypressがあります。
ブラウザで直接動作するため、E2Eテストツールの中では比較的高速でテストできます。
1回試してみてよかった有料ならAutifyがいいと思います。

ESLint Prettier

両者によって、コードの品質を向上させバグを未然に防ぐことで開発効率向上させます。

• ESLint
  コードの構文エラーや潜在的なバグ、コーディング規約の違反を検出するためのツールです。

• Prettier
  Prettier は、コードのフォーマットを統一するためのツールです。

Biome

ESLintとPrettierの統合です。Rustで構築されており、ESLint や Prettier に比べて高速です。

CI(GitHUb Actions)の構築

CIでは以下のメリットがあります。

• テストの自動実行 プッシュやプルリクエスト時にテストを実行して問題を早期発見
• 自動デプロイ 本番環境やステージング環境への自動デプロイ
• Linterの自動実行 コードスタイルや品質をチェックして、クリーンなコードベースを維持

これを毎回手動でやるのは大変なのでCIなどで自動化するといいと思います。

1点注意点です。

• E2EテストまでCIで回すと重いし時間がかかる

Css in JS

JavaScriptの中でCSS（スタイルシートを直接記述する手法のことでスタイルとロジックをコンポーネント内で一元管理します。
ex)

• styled-components
• emotion

Tailwind

CSSフレームワークです。スタイルを小さなパーツに分けて使う方法で、簡単にデザインでき、使い回しができ、変更が簡単なことがメリットです。

MUI

React用のUIコンポーネントのセットで、UIのデザインを作るのを簡単にしてくれます。

ex)
ボタン、テキストボックス、ダイアログなど

よく使われるデザイン要素（コンポーネント）があらかじめ用意されています。
それらを使うことで、デザインを一から作らなくても、きれいで使いやすいUIをすぐに作成できます。

MUIとstyled-componentsを同時に使用すると？

MUIとstyled-componentsを併用する場合、いくつかの整合性や競合の問題が発生することがあります。
MUI は独自のスタイリングシステムを持っており、styled-components はそのスタイリング方法が異なるため、うまく連携しない場合があります。(実際個人開発でありました💦)

shadcn-ui

シンプルで軽量なデザインが特徴です。
shadcn-uiは、シンプルでカスタマイズしやすいデザインで、Material Designのような強制的なデザインガイドラインを持たず、軽量で、ユーザーがデザインを自由にカスタマイズできます。よく使われるデザイン要素（コンポーネント）があらかじめ用意されています。
それらを使うことで、デザインを一から作らなくても、きれいで使いやすいUIをすぐに作成できます。

CSS Modules

CSSのクラスをコンポーネントごとに範囲を限定する仕組みを提供する技術です。

CSS Modulesの観点

MUI、CSS in JSとかだと破壊的変更がありメンテナンスの際に開発工数がかかってしまいます。
それを考慮するとCSS Modulesはメリットがあったりします。

環境構築だけやればいい訳ではない

ユーザーの反応速くみたいので、周辺ツールの導入にばかり力を入れたらいい訳ではないです。大事なのは速くビジネスサイドの意向を汲み取って、プロダクトには反映させることの方が大事です。最悪開発効率が悪くなるのも仕方ないと割り切るのも大事だと思います。優先順位を決めていくことです。

ReactとVue.jsのどちらを採用すべきか

基準	React	Vue.js
規模	大規模なプロジェクトや長期的な拡張性が必要な時	小規模から中規模のプロジェクト
ライブラリの充実度	Vue.jsより充実	Reactほどではないがある
コンポーネント設計	コンポーネントベース、状態管理	単一ファイルコンポーネントで構造がシンプル
状態管理	ReduxやRecoilなどの高度な状態管理	Vuexなどが公式で提供され、状態管理が簡単
学習コスト	Vueより高い	比較的簡単

• Reactは、大規模なアプリケーションや複雑な状態管理が必要なプロジェクトに向いています。
• Vue.jsは、学習コストが低く、小規模から中規模のプロジェクトに向いてます。

ReactとNext.jsのどちらを採用すべきか

Next.jsならSEOやパフォーマンス最適化、SSR/SSGが必要な時に採用。

Reactは自由度を重視し、SEOは特に関係なくシンプルな構成が適切な場合に採用。

Next.jsのpage routerとapp routerのどちらを採用すべきか

　あくまで参考にお願いします。

Next.jsのSSG SSR

以下の記事に両者の違いを記載しております。

参考資料