【Next.js】Next.jsテンプレートを作ってみた

背景

先日、Next.js を用いたフロントアプリケーションを作成しました。

今後、Next.js を使用することがあると思うので、備忘録がてらテンプレートを作成。
※ 作ってみて、「こうすればよかった。。。」という後悔ポイントも多かったので、改善して取り込みました。

テンプレートはこちら

作成したテンプレートは私の GitHub にアップロードしております。

https://github.com/ayakaki/my-next-template

ポイント解説

私のテンプレートのポイントを解説します。

ポイント① src 配下にコードを集約

ルートディレクトリ直下に、src 　ディレクトリを配置し、その中に記述するコードを集約する構成としております。
これによって、コーディングで記述する箇所が明示化され、見やすいディレクトリ構成となります。

ポイント② axios による API コールメソッドを実装

API をコールする util メソッドを用意してあります。
毎度、axios を呼ぶような処理を記載すると、二重記載となる箇所が多々生じてしまうため、保守性の観点から、API コールメソッドを用意しました。

ポイント③ 命名規則

命名規則も徹底してあります。基本的には公式の推奨にのっとれば良いかなと考えております。

• ファイル名
  • pages配下：ケバブケース
  • pages配下以外：パスカルケース
    • jsx要素あり：.tsx
    • jsx要素なし：.ts
• ディレクトリ名：ケバブケース
• クラス名：パスカルケース
• メソッド名：キャメルケース
• 変数名：キャメルケース

ポイント④ コンポーネントの分け方

コンポーネントは、UIベースで分けて、components ディレクトリに格納します。
そして、pages でページ全体のUIを組み立てつつ、コンポーネントを組み込んでいきます。

その際、処理はpages のなかで記述し、コンポーネントに対して、props で渡してあげるのが良いと考えています。（よっぽど処理とUI自体が密接でない限り、使い回しの観点から、コンポーネント内に処理は記述したくない）

ポイント⑤ .env ファイル

.env ファイルも作成しています。

基本的に NEXT_PUBLIC_ を接頭辞として、変数名につけます。
すると、process.env.NEXT_PUBLIC_HOGEという形で利用することとが可能です。

ポイント⑥ export default は基本使用しない

pages 配下以外は、export default 使用せず、 export の記載にしています。（ pages は自動的に画面になるものなので、Next.js の決まり的に export default での記述が必須）

なので、インポートする際は、import hoge from ~~ ではなく、 import {hoge} from ~~ となります。

あえて export を利用する理由は、コンポーネントの修正において、強制的にインポート元のことを意識させるためです。

export default を使用すると、インポート元で関数名を指定する必要がなくなります。（from ~~ にてファイルパスが合っていれば、関数名が間違っていてもインポートできてしまう）

そのため、コンポーネントはインポート元を意識せず、関数名を変えられることになってしまいます。
すると、関数名が勝手に変えられ、そしてその新しい関数名の範囲内で、処理が変更されることが想像されます。

そうなると、インポート元の従来の想定から外れたコンポーネントに変化していってしまう可能性が高まります。

そのため、私は、export を使用して、ファイル名を強制したいと考えております。

このテンプレート以降のマスト実装

このテンプレートはどのプロジェクトでも共通する可能性が非常に高い部分のみをまとめてあります。

そのため、下記のような実装方法が分かれそうなものに関しては、含めておりません。

• CSS
• レスポンシブデザイン
• 状態管理

この章では、残りのマスト実装と 2022年12月時点で私が考えるベスト案を紹介します。

マスト実装① CSS の適用

1 つ目のマスト実装は CSS の適用 です。
React.js／Next.js では、CSS の実装方法は複数あります。大きく分けると、下記 3 種類です。

項目	内容
Pure CSS	シンプルに全コンポーネントで全CSSを読み込み、クラス名でセレクタを分ける方法 ※BEMなどの設計思想と合わせる（だと思ってる）
CSS Modules	コンポーネントごとに必要なCSSファイルを読み込む方法（自動的にクラスファイルは唯一にしてくれる）
CSS in JS	tsxファイル・jsxファイル内にCSSを記述する方法

個人的に、ある程度、CSSに慣れている方は CSS in JS がいいのかなと考えています。emotion の使い勝手はよいです。（他の CSS in JS は使ったことはないですが。。。）

tsxファイルに記載するので、エディタの補完機能が出ませんが、同じファイルにマークアップ・処理がまとまっているのは見やすいし、管理がしやすいです。

CSS に慣れていない場合は、 CSS Modules がおすすめです。

CSS Modules のメリットは、エディタの CSS 補完機能が使える点です。css ファイルでの記述となるためです。

React／Nextはコンポーネント指向のため、ただでさえ、ファイルが多いのに、tsx ファイルとは別に CSS ファイルを作成するとなると、ファイル数が2倍となってしまうため、ちょっと避けたいというのが正直なところなので、僕は第一候補からは外しました。

Pure CSS は CSS の設計思想も理解することが必要とされると考えられるため、学習コストが高くなる点から候補から外しました。

マスト実装② レスポンシブデザインの適用

2 つ目のマスト実装は レスポンシブデザインの適用 です。

レスポンシブデザインの実装方法は僕の知っている限り、3 つあります。

実装方法	詳細
メディアクエリ	CSS ファイル内における @media の記述で画面幅ごとに CSS を切り分ける方法
use-media	npm パッケージの use-mediaを用いて、画面幅ごとにコンポーネントを出し分ける方法方法
window.innerWidth	画面幅ごとにコンポーネント・スタイルを出し分ける方法

個人的には、window.innerWidth を用いた方法が良いかなと考えています。

好みではありますが、この方法がコードが一番綺麗かなと思います。

コード例は後日記載します。

マスト実装③ 状態管理

3 つ目のマスト実装は 状態管理 です。

状態管理において有名な手法が下記の 2 つです。

• Redux
• Recoil

どちらでもよいのですが、私は Recoil 派です。（というより、Recoil しか使ったことがない）

Recoil は　useState と同じように使えるので、とても使い勝手がよいという印象です。

最後に

私自身、まだまだ React.js／Next.js の経験としては浅い部分もありますが、結構色々なことを試してみた結果です。参考になりましたら、幸いです。

最後までお読みいただき、ありがとうございました。