Closed trancore closed 8 months ago
Next.jsでは、テンプレートがJS内で記載される(JSX)ことから、CSS-in-JSの方が親和性が高い気がする。 とすると、CSS modulesかStyled Componentがよく使われているものになるため、この2つから選定したい。
-
をつけてしまうと、書き方が変わってしまう。以上を鑑みつつ、まだstyled componentを触ったことがないので、Styled Componentで実装する。
TODOアプリでは、あまり複雑な状態管理を行わない or 不要な気もするが、一旦調べてみる。
Provider
配下のコンポーネントでContextが要求された時、value
で指定した値を供給する。Atom
で状態をもち、それを各コンポーネントでgetter
, setter
を呼び出す。Selector
でAtom
や別のSelector
を呼び出し、再計算させる。調べてみたが、Recoil, jotai, zustandのライブラリは学習コストが低く、簡単に扱える印象を受けた。 また、いわゆるAtomパターンで、どこからでも手軽に状態の取得・更新ができる利点がある。しかし、あまり深く考えずに状態の更新をしてしまうと、予期せぬ状態の更新が起こってしまうのではないだろうか。
一方古くからあるReduxは、学習コストは高く理解するにはそれなりに大変。 しかし、堅牢な状態管理フローは一度理解してしまえば扱いやすいのかも。
以上を考慮して、Reduxフローを学び直したい、手軽すぎると学習に向かなさそう、RTK Queryを使いたいので、Reduxで状態管理を行う。
Next.jsでは、Server側とClient側でfetchの方法が異なる。 Server側では、getServerSideProps, React Server Components(RSC)がある。 Client側では、SWR, TanStack Query, RTK Query, useEffectがある。 さらに、fetcherには、Axios, fetch, graphQLがある。
Pages RouterでSSR時に処理を行うための関数。 Pages Routerでは、pre-renderingによってHTMLが生成される。この時、ページのリクエスト毎にHTMLを生成するのがSSRとなる(一方で、build時にHTMLを生成するのはSG)。 だが、このgetServerSidePropsというのはNext.js独自の概念で、React.jsでは存在しない。
最新の情報を取得し、HTML生成とともにデータが揃っていれば、ページ解析時により良いページ情報を提供できることになり、SEOにも良い影響がでる。もちろんこれはSG時も同じ(しかしSGの場合、buildを頻繁に行わないとデータの鮮度が落ちる)。
React.jsでの概念で、Server側でレンダリングされるコンポーネントとClient側でレンダリングされるコンポーネントで分けることができるようになった。 そして、SSRの場合は、Client側のコンポーネントでもSSRでレンダリングすることができる(ちなみにSSR無しでは、Server側のコンポーネントだけHTMLにgenerateされる)。 このRSCを使うことで、パフォーマンスの改善とバンドルサイズの軽減をすることができる。
コンポーネントを外部システムと同期させるためのReact Hooks。 コンポーネントのトップレベルかカスタムフック内でしか呼び出せない。 画面描画後に実行されるため、ちらつきが起こる場合は、useLayoutEffectを使う。 さらに、state更新の際にも再描画を行なってしまうため、この場合もuseLayoutEffectに置き換える必要がある。
SWRはキャッシュ機構を持ちつつデータフェッチを行うことができる。 SSRやISR, SSGにも対応している。 RSCを使う場合は、Client側コンポーネントでのみ使うことができる。
RTK Queryも、データフェッチとキャッシュに対して強力なツールとなる。シンプルにデータの読み込みするようにデザインされており、手書きでデータの取得やキャッシュを書く必要がなくなる。 Redux toolkit packageに含まれるアドオンである。 Reduxを使っているなら、これを使うのが良いかも。
元はReact Query。 データフェッチによる取得や更新、キャッシュ機能を持つ。 バンドルサイズも小さく、やれることも他に比べて多そう。 Comparison | React Query vs SWR vs Apollo vs RTK Query vs React Router
上記調べたが、
Server側は、最近導入されたRSCを触ってみたいため、RSCを導入することとする。
Server側は、Styled-componentがApp Roterに対応していないため、Pages Routerでの取得に変更する。(2024/02/18)
また、Client側は、状態管理ツールとしてReduxを使うため、RTK Queryを使う。
すでにAPIサーバーの開発は完了しているため導入するメリットが無いが、やってみたいので、実装することとする。
App Routerの場合では、Route Handlerを使うことで、データフェッチを扱うことができる。 これで持ってモックデータを定義し、fetchからパスを指定すればモックデータとして値を取得できそう。 ライブラリなどを入れる必要がなく、フレームワークが提供する機能なので安心。 サーバーをいちいち立てる必要も無い。
npm packagesを追加すればすぐにリクエストできるmockサーバー。 DB(keyvalue型のlowDB)の定義もできるので、POST, PUT, DELETEなどもリクエストすることができる。 Swaggerを取り込むことはできないので、APIを一つ一つ手動で定義する必要がある。 REST API, GraphQL APIにも対応できる。 リクエストそのものをインターセプトしているので、環境変数ひとつで本番環境、開発環境へのアクセスを切り替えることができる。
環境やフレームワークに影響されないJSのAPIモックライブラリ。 Devtoolsでモックされたレスポンスを見ることができるし、Service Workerに書く必要がない。さらにテストでも使えるみたい。 Service Worker(ブラウザ)、Node.js(サーバー)でも動くので、SSR/CSRにも対応している。ブラウザで動かす場合と、サーバー上で動かす場合とで設定方法が異なるのに注意。 Swaggerを読み込んで、設定無しによしなにやってくれる機能はない。この辺りは自分で実装する必要がある。 (参考:Generate API responses from swagger doc)
msw以前は、Jestを使ったモックサーバーがよく使われていたそう。 Jest - モック関数 - モジュールのモック
そもそも、jestがtesting libraryであるため、テストと組み合わせる場合は良さそう。 しかし、テストのためのモックであり、画面開発としてのモックサーバーとしては使い勝手が悪そうと思った。
OpenAPIでのAPIモックとテストを行うことができるパッケージ。 そのため、Swaggerを読み込ませれば、すぐにAPIモックとしてリクエストをすることができる。Swaggerがあればお手軽にモックサーバーを建てられる。
上記より、mswかprismになる。 prismはお手軽すぎるがレスポンスを自由に変えるための実装をしてみたい。mswは触ってみたいが、導入から使えるまでに時間がかかりそう、、 悩んだ末、mswで実装することにする。
Next.js公式によると、テストの段階によって、テスティングライブラリを使い分けることが説明されている。
テストも書いていきたいので、単体テストはJest, testing-libraryを使って書いていく。 ちなみに、testing-libraryを入れる理由は、便利なテスティングマッチャーが使えるようになるから。 結合テストはCypressを使っていく。
以上技術を使って実装していく。
さらに忘れていた。。
まとめてくれている記事を添付しておく。 Qiita - Reactのフォームライブラリを比較してみる
こちらにまとめてくれているように、React-Hooks-Formを使う。
さらにさらに忘れていた。
ドメインルーティングを使って、ドメインごとに言語情報を分ける。
URLのパスに言語情報を含める。
これらパッケージのトレンドは以下のリンク先の通り。 npm trends
調査時の順位は以下の通り。
The i18n routing support is currently meant to complement existing i18n library solutions like react-intl, react-i18next, lingui, rosetta, next-intl, next-translate, next-multilingual, tolgee, paraglide-next and others by streamlining the routes and locale parsing.
公式では、ライブラリありきっぽい。国際化ライブラリを補完するもの、という説明をしている。
なので、built-inだけで実装するのは想定していなさそう。
npm-trendsの順位とNext.jsのドキュメントで紹介されているnext-i18next
を使用したいが、next-i18next
はCommonJSしか対応していないため、next-intl
を使う。
さらにさらにさらに忘れていた
https://nextjs.org/docs/pages/building-your-application/optimizing
Next.jsでは、どのようなSEO対策を行うことができるのか。
タスク概要
参考になりそうな資料
作業
完了条件