nextjs

nextjsでタグマネージャーを導入する際に、本番環境、検証環境、開発環境といった環境ごとにコンテナのIDを指定することにした。 ただnextjsでは用意されたenvと適応コマンドがすでに割りついているっぽい。 環境ファイル 役割 .env.local next dev .env.development next dev .env.production next build/next start 参考：Next.jsで環境ファイル(env)別ビルドを行う 参考：Add support for custom environments 今回は、同じnext startで3つの環境を作成したいけど、前述の通りそれだと.env.productionしか呼び出すことができない。 そこでenv-cmdを使用する。 #Using custom env file path To use a custom env filename or path, pass the flag. This is a major breaking change from prior versions < 9.0.0-f とあるように、アプリをビルド/実行するときに特定の.envファイルを選択することができるパッケージ。 .env.prod .env.stag .env.local と3つのEnvを用意し下記のようなScriptを作成すれば、それぞれのScriptごとに対応するEnvを読みに行ってくれる。 "prod": "env-cmd -f .env.prod next build && next start", "stag": "env-cmd -f .env.stag next build && next start", "local": "env-cmd -f ....

新規開発中のWebアプリケーションで、一覧ページのネットワークタブを何気なく確認したら、画面に表示されているリストの各詳細ページがすべてリクエストされていることに気付き、驚いた。 「実装ミスかしら」とぞっと総毛だって実装を見直してみるが、特段へんてこな記述は見つけられない。 ただnext/linkをmapで回しているだけである。 だいたいこういうときはnextのお節介が原因のことが多い。 そういうわけで、next/linkを調べてみると案の定prefetchというオプションがあり、デフォルトがtrueとなっていた。 ビューポート内にある はすべてプリロードされます (初期状態やスクロール中)。prefetch={false} を渡すことでプリフェッチは無効になります。prefetch が false に設定されている場合でも、ホバー時にはプリフェッチが行われます。静的生成を使用しているページでは、ページ遷移を高速化するためにデータと一緒に JSON ファイルがプリロードされます。プリフェッチは本番環境での> み有効です。 とのこと。 基本的に気にしなくてもいい気がするけど、サーバーに負荷をかけるのでfalseにしても問題ない気がする。 prefetch が false に設定されている場合でも、ホバー時にはプリフェッチが行われます とあるのでfalseにしたところで、そこまでページ遷移のユーザー体験を損なわないと思われる。 nextは本当にお節介で裏側で色々なことをしてくれる。しっかり理解しないと思わぬ副作用を生むことがあるのでドキュメントを読むことを心掛けたい。

レビューは勉強になる 最近案件が立て込んでいるのは6月のまとめに書いたんだけど、結果いくつかのプロジェクトで実装ではなく、ただのレビューアーと化している。 実装がしたいって今まで強く思っていた。 実装が実力を伸ばす唯一の手段だと思っていたけど、レビューも真剣にやればすごい勉強になることに気が付いた。 というのもレビューするには、まずコードをしっかり読まなければならないし、知らないプラグインとの出会いがあり、それを調べることで相当勉強になる。 で、今回出会ったのが、class-variance-authorityというプラグイン。 class-variance-authorityとは?? 簡単に言うとvariantsを定義して条件分岐をわかりやすくするもの。 公式にあるbuttonコンポーネントの例がわかりやすい。 import React from "react"; import { cva, type VariantProps } from "class-variance-authority"; const button = cva("button", { variants: { intent: { primary: [ "bg-blue-500", "text-white", "border-transparent", "hover:bg-blue-600", ], secondary: [ "bg-white", "text-gray-800", "border-gray-400", "hover:bg-gray-100", ], }, size: { small: ["text-sm", "py-1", "px-2"], medium: ["text-base", "py-2", "px-4"], }, }, compoundVariants: [{ intent: "primary", size: "medium", class: "uppercase" }], defaultVariants: { intent: "primary", size: "medium", }, }); export interface ButtonProps extends React....

フロントエンドを開発するときにバックエンドサーバ―の用意ができていない時がよくある。 今までは側だけ作って待機していたが、せっかくなのでモックサーバーを立ち上げ、バックエンドができ次第、URLの向きを変え、完成！ という風に出来ればと思いモックサーバーの立ち上げを調べてみた。 json-server まずはjson-serverを使おうと思ったけど、同じエンドポイントでGet、Postが分けられなさそうということで不採用にした。けど、よくよく落ち着いて調べてみるとできるかもしれない。 いつか機をみて使ってみたい。 が、今回は上記の通り不採用した。 app/api 次に、そもそもnextjsにはAPIを作る機能があるじゃないかと思いだし、それを活用することにした。 ついでにAPI仕様書も作れればなおいいということで調べてみると、next-swagger-docというものがあった。 これでAPIを作成し、しかもSwaggerを作成できると舞い上がり実装してみた。 実装 npm i next-swagger-doc npm i swagger-ui-react まずはインストールする。 ちなみにバージョンは下記の通り。 "next": "14.2.3", "next-swagger-doc": "^0.4.0", "react": "^18", "swagger-ui-react": "^5.17.14" lib/swagger.tsに下記をコピペする。 import { createSwaggerSpec } from "next-swagger-doc"; export const getApiDocs = async () => { const spec = createSwaggerSpec({ apiFolder: "app/api", // define api folder under app folder definition: { openapi: "3.0.0", info: { title: "Next Swagger API Example", version: "1.0", }, components: { securitySchemes: { BearerAuth: { type: "http", scheme: "bearer", bearerFormat: "JWT", }, }, }, security: [], }, }); return spec; }; ※以降先頭行がファイル名になっている。...

Dockerで環境構築したファイルを変更してもブラウザで表示が変更されない そもそも作成した環境は下記記事の通り。 DockerでnextJsとnestJsの環境構築をする で、色々検証してみた結果、Dockerを止め、再度立ち上げれば更新されているということが分かった。原因が分かった、これで一件落着とはならない。 何でも不便すぎる。 そこでホットリロードが効くように調査してみた。 結論（いったん諦める） フロントエンドに限り、ブラウザを更新すれば、表示が更新されることは確認できた。 フロントエンド（NextJs） フロントエンド（NextJs）側の設定は、docker-compose.ymlに下記変更を加えたらホットリロードが効くようになった。 frontend: build: context: . dockerfile: ./docker/frontend/Dockerfile tty: true volumes: - type: bind source: ./frontend target: /app + environment: + - WATCHPACK_POLLING=true ports: , "3333:3333" …ただめちゃくちゃ重い。 何回かやっていると、なんかうまくいかなくなったので、 上記の追加分を削除し、下記で対応した。 next.config.jsに下記を追加。 webpackDevMiddleware: config => { config.watchOptions = { poll: 1000, aggregateTimeout: 300, } return config }, これで同じく重いけど、リロードに対応した。 ホットリロードにも対応しているようだけど、Dockerが重すぎてわからない。 バックエンド（NestJs） NestJsを色々調べてもよくわかなかったので、Dockerについて調べると、下記記事を見つけた。 Dockerを使っていてhot reload系が効かなかったとき この１つ目「wsl上にファイルを置いていない」が該当したので、確認してみることにした。 が、これがなかなか厄介で大変な気がする。 もっと簡単そうなのが、 env CHOKIDAR_USEPOLLING=true をDockerfileに記述する。 あるいは、 environment: - CHOKIDAR_USEPOLLING=true をdocker-compose.ymlに追記するというもの。...