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

# なぜこの記事を書いたのか
以下の理由で作成しています。

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

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

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

https://qiita.com/Hashimoto-Noriaki/items/79d11cf6944dca653b5f

# 検証で使ったソースコード
- Next.jsの環境構築

https://github.com/Hashimoto-Noriaki/next-schedule-app

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

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

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


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

https://qiita.com/hinako_n/items/0f1e9e9b56a888d86641

# コンポーネント設計
***AtomicDesign***が1番有名です。

https://qiita.com/Hashimoto-Noriaki/items/1faea0254dd48fc232dd

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

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

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

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

https://zenn.dev/yodaka/articles/eca2d4bf552aeb

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

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

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

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

・自分の記事です。

https://qiita.com/Hashimoto-Noriaki/items/2eb3587287ea82c141d8

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

https://github.com/kufu/smarthr-ui?tab=readme-ov-file

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

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

# OpenAPIを用いたスキーマ駆動開発(Swagger)
API の仕様を記述したスキーマを中心に開発を進める手法です。

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

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

・自分の記事です。

https://qiita.com/Hashimoto-Noriaki/items/8695e6c290519f3d7670


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

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

・自分の記事です。

https://qiita.com/Hashimoto-Noriaki/items/31911997046ce91e4e3b


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

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

https://nextjs.org/docs/pages/building-your-application/testing/cypress

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

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

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

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

https://zenn.dev/akineko/articles/d967d5dcada598

# CI(GitHUb Actions)の構築
CIでは以下のメリットがあります。

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

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

1点注意点です。
- ```E2EテストまでCIで回すと重いし時間がかかる```

https://qiita.com/Senritsu420/items/f51a7eff81a8c1372302

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

https://qiita.com/Hashimoto-Noriaki/items/1f5454b0d3d56c104b51

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

https://qiita.com/Hashimoto-Noriaki/items/3c2c7fe759895b26f53c

# 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のクラスをコンポーネントごとに範囲を限定する仕組みを提供する技術です。

https://www.commte.co.jp/learn-nextjs/CSSModules

### 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は特に関係なくシンプルな構成が適切な場合に採用。 

https://qiita.com/Hashimoto-Noriaki/items/600353ebb34adc05b0e0

# Next.jsのpage routerとapp routerのどちらを採用すべきか
　あくまで参考にお願いします。
 
https://qiita.com/Hashimoto-Noriaki/items/c5bce236067b22d38d64

# Next.jsのSSG SSR
以下の記事に両者の違いを記載しております。

https://qiita.com/Hashimoto-Noriaki/items/d531e26beec657ae016d


# 参考資料

https://zenn.dev/yukionishi/articles/4c02ece789c34daadda5