Next.jsを使用するということ
本ブログのアナリティクスを見てみると、サーバーサイドレンダリング(以下 SSR)について調べている中で辿り着く人が多いみたいです。
最近業務でもプライベートでもかなり Next.js を触っているので、経験から得られた知識をだらだらーっと書いていこうと思います。
React を用いた開発
React を用いて開発を行うとなると、恐らく以下のいずれかのパッケージを使用することがほとんどだと思います。
一番使用されていると思われるのが Next.js 、ついで Create React App、Gatsby と続くと思われます。
過去にも書いてきましたが、脳死で Next.js を選択することは個人的にはあまり賛成できません。
それぞれのパッケージによって得手不得手が分かれていますので、要件に沿って最適な選択を行うべきだと思います。
Next.js を選ぶ理由
上記のパッケージの中で、Next.js は SSR に対応しているというのが大きなメリットとして挙げられます。
SSR とは一体なんぞや？ということについては本ブログで何度か触れてきたので、今回は省略します。
SSR を使用するメリットは以下の通りです。
- ファーストビューにおける動的なデータの描画が早く、描画が崩れない
- 動的なページの SEO が対応可能
また Next.js は初期状態で静的サイトジェネレーター(以下 SSG)に対応しているため、以下のメリットも享受できます。
- ファーストビューの描画が早い
ただし Create React App については react-snap を導入することで、Gatsby については初期状態で SSG に対応しているため SSG については Next.js だけが持つ強みというわけではありません。
加えて、Next.js 自体が持っている強みを挙げると。
- Api の構築 が非常に容易であり、サーバーサイドまたは BFF の組み込みが楽
- Vercel というホスティングサービスを使用するとデプロイ周りが自動的に構築され、アナリティクスまで見ることができるようになる
- 多言語対応が容易
上記の要件を満たしたいケースでは Next.js が最適な選択になると思われます。
具体的には以下ようなケースで Next.js は強さを発揮すると思われます。
- 動画サイト
- レシピサイト
- ショッピングサイト
上記のケースに統一していることは、各々の詳細ページにおいて対応する SEO の反映が必須ということです。
Next.js でなくて良いケース
逆に以下のようなケースでは Next.js を選ぶ必要はないかなーと思います。
- 個人や会社のホームページ
- ランディングページ
- ブログサイト
また動的なデータを扱う場合であったとしても、そのデータを SEO に反映する必要がないのであれば Next.js でなくとも仕様を満たせるケースは多いです。
加えて Next.js を使用する場合、必然的にサーバーサイドとクライアントサイドをまたいで開発することになるため、以下の知識が求められるようになります。
- サーバーサイドで使用できない技術の把握(Storage 系や widnow オブジェクトなど)
- Cookie の扱い方
- サーバー負荷の対策(SSG の組み方)
- クライアントサイドとサーバーサイドをまたぐ処理について
過去何度も書いてきましたが、個人的に SSR とは決して容易に扱えるものではないと思っています。
Next.js を選ぶ場合は Next.js でなければならないケースでのみ選ぶようにしましょう。
Next.js の開発難易度は高い
HTML や CSS、JavaScript の知識が半端であったり、React がよくわかっていなかったり、1 からフロントエンドのプロジェクトの構築を行ったことがない場合も Next.js を扱うべきではありません。
必ず Frontend Developer 及び React Developer のロードマップに沿って勉強を進めることを心がけましょう。
Next.js を使用している中で詰まったポイントや疑問
SSR の正しい知識を持っていれば Next.js の開発において詰まることは少ないですが、開発序盤ではたまにつまずくこともありました。
思い出せる範囲で書き出していこうと思います。
Cookie の扱い方がわからない
クライアントサイド及びサーバーサイドにおいて Cookie を扱う必要が出てきたときに、最初はどう実装すれば良いのかわかりませんでした。
結論から書くと nookies を使用すれば解決できます。
恐らく実装すれば Cookie の格納場所はわかると思いますので、細かいことは省略します。
サーバーサイドで画面サイズが取得できない
サーバーサイドにはブラウザという概念が存在しないため、必然的に window オブジェクトは取得できません。
useState や useMemo において window オブジェクトにアクセスしないようにしましょう。
サーバーサイドでストレージにアクセスできない
「サーバーサイドで画面サイズが取得できない」と同じ理由です、同様の対応を行うようにしましょう。
Redux との相性ってどうなの
はっきり書くと相性は良くないです。
Next.js と Redux はあまり組み合わせる必要はないと思うのが個人的な意見です。
個人的に Redux の一番のメリットは Api の呼び出しを Redux に寄せることが可能なことだと思っています。
一方 Next.js が Api 周りのルーティングを提供している以上、Redux が効果的に発揮されるケースは少ないと思います。
めちゃめちゃストレージを扱うケースとかであれば便利かもですが…。
State of JS 2020 を見ても、Redux や MobX の満足度は下がり調子です。
恐らく今後 Redux は廃れていく一方かなーと予想されます。
思ったよりも書けることが少なかったです。
逆に言うと Next.js がそれだけ優れたフレームワークなのかなーと思います。
サーバーサイドレンダリングは必要だ不要だと連日盛り上がっていますが、個人的にはまだまだ手放せないかなーという印象です。
自身の経験から感じるのは、思考が極端なエンジニアがちょっと多いかな？と思っています。
0 か 100 かでしか判断できないエンジニアを見ていると、極端な思考は経験の狭さ及び薄さ、浅さによって固められていくのかなーと個人的には感じます。
ケースバイケースという言葉の通り、ケースによって最適な解答を選択できるようになることが大切なのかなーと思う、今日このごろです。