Next.js 15.3 includes Turbopack for builds, new client instrumentation and navigation hooks, and more: Turbopack for builds (alpha): Faster production builds passing 8000+ tests (99%) Community support for Rspack (experimental): Alternative bundler with Webpack compatibility Client Instrumentation hook: Early monitoring and analytics setup Navigation hooks: Control routing with onNavigate and useL
To ensure Next.js can be deployed anywhere, including severless platforms with custom requirements, we are planning to add deployment adapters. Vercel will use the same adapter API as every other partner. Background Next.js has supported self-hosting since 2016, including ejecting out of the Next.js server to a fully custom Express server. This includes deployment as a Node.js server (next start),
IntroductionRecently, Yasser Allam, known by the pseudonym inzo_, and I, decided to team up for some research. We discussed potential targets and chose to begin by focusing on Next.js (130K stars on github, currently downloaded + 9,4 million times per week), a framework I know quite well and with which I already have fond memories, as evidenced by my previous work. Therefore, the “we” throughout t
概要 Pages Router から App Router 移行時に一部既存の画面での CSR 遷移が 404 エラーになりました。 この件について調査したので、記事にしてまとめておきます。 前提 今回発生したバグの内容の再現環境の特徴として、以下が挙げられます。 Next v13.5.6 Base path の設定あり App Router と Pages Router が共存している Base Path について Base Path の設定は next.config.js に以下のような記載があると、 module.exports = { basePath: '/base', } /pages/examples.tsx で配置したページコンポーネントが、 URL /base/examples で閲覧できるようになるものです。 また以下のような Link コンポーネントは、自動的に Ne
IntroductionSome time after publishing my previous research on Next.js, I was left with a feeling of unfinished business. That work had sparked my curiosity, and I sensed that this framework still had more secrets to unveil. So, I grabbed my pickaxe once more and delved back into the depths of its source code. It turned out to be a good decision. The findings from this new research have had a sign
概要 フォームの入力中に離脱すると入力中の内容が失われてしまいます。離脱前に確認ダイヤログを挟むことで意図せぬ入力内容の消失を防ぐことができます。 離脱には以下の 2 種類があります。 ブラウザ操作による離脱: タブを閉じる、更新する、ブラウザナビゲーション（戻る、進む） Next.js のルーティングによる離脱: Next.js の機能で別ルートに遷移する このうち 2 は Next.js の router.events という機能でイベントを検知&キャンセルすることになりますが、この機能が App Router から使えなくなりました。 現在フィードバックが集まっていますがコントリビューターから明確な回答が得られておらず、この機能が復活するのかも不明な状況です。 2024年5月8日追記: Lee Robinson 氏より正式な回答が得られましたが依然ハッキーであるため、よりスマートな解
初めまして，トモニテ開発部でSoftware Engineer(SE)をしている鈴木です． SEチームはAPI開発からそのAPIを利用したweb開発まで幅広い領域を担当しており，トモニテ開発部のweb開発には Next.js を採用しています． また，エブリーの開発部では定期的に挑戦week(※)なるものを開催し，技術的観点から事業貢献を行う1週間を設けており，その中でNext.jsのPages RouterをApp Routerに移行する機会を頂けたので紹介させていただきます． ※ 挑戦weekについては以下のオウンドメディアで記事にしています．今回の挑戦weekは事業部の垣根を超えたチーム編成で行い，大変面白いものでした！ エンジニアが楽しみながら開発体験を向上させる「挑戦week」を実施しました！ 背景 Next.jsでルーティングを行う際， v13以前はPages Routerを利
Next.js@15.1から実験的にミドルウェアのテストヘルパーが追加されました。 なぜかv15.1のリリースノートにも書かれてないため、まだまだ破壊的な変更が入るかもしれない点に注意が必要です。 このヘルパーはApp Router, Pages Router両方共に対応しています。 提供されているヘルパー 2つのヘルパーが提供され、2軸でのテストを行っていきます。 unstable_doesMiddlewareMatch そのミドルウェアがリクエストにマッチするかどうかをテストする ミドルウェアのconfig と next.config.ts での rewrites の両方共を確認できる あくまでも中身のロジックを確認するわけではない isRewrite, getRewrittenUrl そのミドルウェアが実際に期待している挙動をするかどうかをテストする コード例 middleware.
あけましておめでとうございます。もう2025年とは早いですね。まだ2024年くらいの気持ちです。不思議ですね。 年が明けてやりたいことといえば今年の目標を立てる、という方が多いかなと思います。僕はそういう人間ではないというか、目標を立てても三日坊主とは言わないまでも1ヶ月くらいで目標とはなんだったのか、となってしまうことが多いので、近年は目標は意識していません。 そんな僕でも今年は意識していきたいことが一つあります。それは「Next.jsでNEXT_PUBLIC_のプレフィクスをつけた環境変数は乱用しない」です。同じような目標を立ててる方もきっと多いことでしょう。ということでその話を書いておきます。あとここからは「ですます調」ではなくなります。 Next.jsの環境変数 このエントリではNext.js 15 + App Routerについて書いている。環境変数については、まあ基本はここに書
"use cache"は、Next.jsのDynamic IOで利用することができる新たなディレクティブです。本稿は筆者の備忘録を兼ねて、Dynamic IOの成り立ちや"use cache"の内部実装について解説するものです。 Dynamic IOの成り立ち Dynamic IOは2024年10月のNext Confで発表された、Next.jsにおける新しいコンセプトを実証するための実験的モードです。Dynamic IOはその名の通り、主に動的I/O処理に対する振る舞いを大きく変更するものです。 具体的には、以下の処理に対する振る舞いが変更されます。 データフェッチ: fetch()やDBアクセスなど Dynamic APIs: headers()やcookies()など Next.jsがラップするモジュール: Date、Math、Node.jsのcryptoモジュールなど 任意の非同期
こんにちは。 Findy Toolsの開発をしている林です。 私たちのプロジェクトではフロントエンドのフレームワークにNext.js App Routerを使っており、AWSのECSへデプロイして運用しています。 そして、一部のレンダリングの処理が重いページのキャッシュを実装する際に、直面した課題と解決策を紹介します。 Next.jsのキャッシュ機構について 今回実現したいこと 課題と解決策 課題1: Next.jsの機能では要件に合わない 解決策1: CloudFrontのみでキャッシュ 課題2: エラーページがキャッシュされる 解決策2: Lambda@Edgeを用いたCache-Controlヘッダー制御 まとめ Next.jsのキャッシュ機構について まず、Next.jsのキャッシュ機構について簡単に説明します。 Next.jsではサーバサイドで使えるキャッシュ機構が次の3種類あり
Next.js の "use cache" ディレクティブによるキャッシュ制御 Next.js の App Router はデフォルトでキャッシュされる設計でリリースされました。一方でデフォルトでキャッシュされることに対して不満を持つ開発者も多かったように思います。このようなフィードバックを受けて、Next.js 15 ではいくつかのキャッシュ戦略が変更されました。さらに現在 canary チャンネルで提供されている dynamicIO フラグを有効にすることで、"use cache" ディレクティブを用いてキャッシュを制御できるようになります。 Next.js の App Router では最もパフォーマンスの高いオプションで提供されるために、デフォルトでキャッシュが有効になっており、必要に応じてオプトアウトする設計でリリースされました。例えば global fetch 関数に patc
Cloudflareが@opennextjs/cloudflareを発表 2024年9月末に開催された「Builder Day 2024」でNext.jsアプリをCloudflare Workersにデプロイする新たな方法が公開された。 この方法は、@opennextjs/cloudflareを使ってビルドする。既存の@cloudflare/next-on-pages方式を置き換える可能性があり、現在は実験的な段階だ。 以下に新旧の開発手順のドキュメントがある。 新(opennextjs): Next.js | Cloudflare Workers docs 旧(next-on-pages): Get started | Full-stack (SSR) | Next.js apps OpenNextの概要 OpenNextは、Next.jsアプリをVercel以外のインフラにデプロイでき
こんにちは！プロダクトエンジニアのshiraです。 2024年6月にリリースした採用管理機能の開発をしています。 support.smarthr.jp 採用管理機能ではNext.jsのApp Routerを採用しています。SmartHRではこれまでApp Routerを使ったプロダクトがない状態だったので、技術選定時は採用するか迷いました。 この記事ではApp Routerを採用するまでの経緯と採用してみてどうだったかについて紹介させていただきます。 Pages RouterとApp Routerについて まずはじめにPages RouterとApp Routerについて軽く説明します。ご存知の方は読み飛ばしてください。 2024年9月現在、Next.jsのルーティングシステムは2つ用意されています。それがPages RouterとApp Routerです。 Pages RouterはNe
17年周年のWebアプリケーションにTanStack Queryを導入する / Implementing TanStack Query in a 17th Anniversary Web Application
目次 はじめに Colocation を意識した設計方針 Parallel Routes と Intercepting Routes を用いた設計パターン サーバー側に処理を寄せたことによる恩恵と課題 Next.js が抱える課題 おわりに 参考文献 はじめに ジャンプTOON のWeb版（以降、ジャンプTOON Web）の開発を担当している浅原昌大（@assa1605）です。 5 月にサービスを開始した「ジャンプTOON」は、オリジナル縦読みマンガ作品や人気作品のタテカラー版を連載する、ジャンプグループ発の新サービスです。 ジャンプTOON のフロントエンドには、Next.js を採用し開発をしています。 本記事では、Next.js の最新機能や設計パターン、Next.js を採用した恩恵と現在の課題について紹介します。 Colocation を意識した設計方針 Parallel Rou
先日、Next.jsの新たなレンダリングモデルであるPartial Pre-Rendering(以降PPR)について記事を投稿しました。 この記事を書いてる時は意識してなかったのですが、感想でアイランドアーキテクチャに言及されるケースが散見されました。社内で上記記事の話題になった時も同様に、アイランドアーキテクチャとの違いについて問われました。 結論から言うと、PPRとアイランドアーキテクチャは全く異なるものです。本稿ではPPRとアイランドアーキテクチャの違いについて解説します。 PPR まずはPPRとアイランドアーキテクチャの概要を改めて整理しましょう。 PPRはページをstatic renderingとしつつ、部分的にdynamic renderingにすることが可能なレンダリングモデルです。具体的には、画面をbuild時(もしくはrevalidate後)に静的生成しつつ、リクエスト毎
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
