AI Agentの進化は目覚ましく、日々実装の品質も向上しています。しかし、開発者自身に明確な実装イメージがある場合、それをAI Agentに出力させることは難しく、さまざまな工夫を必要とします。Agentに与えるコンテキストやプロンプトを最適化したり、詳細なルールを整備することで精度を高めることができますが、これらには大変な労力を伴います。 筆者がNext.jsアプリケーションを扱う場合、実装イメージは著書『Next.jsの考え方』の内容に沿って生成されるため、「この本をAI Agentに読ませることで、アウトプットの精度を高めることができるのではないか」と考え、様々な検証を行いました。 本稿では検証を通して筆者が得た、AI Agentのアウトプットに『Next.jsの考え方』を反映するプラクティスについて紹介します。 要約 以下の条件を満たすことで、AI Agentのアウトプットに『N

アプリケーションユーザーにとってパフォーマンスとは、特定の指標に基づいて判断される定量的なものだけでなく、アプリケーションの総合的な体験を通じて感じる定性的なものでもあります。そのため、ユーザーがアプリケーションを「遅い」と感じる要因は様々です。 Googleは以前より、ユーザー中心のパフォーマンスを提唱しています。Core Web Vitalsは、ユーザーが感じるパフォーマンスを定量的に計測するために作成された指標群で、現在最も重要なパフォーマンス指標の一つです。しかし、Core Web Vitalsだけではパフォーマンスに関するUXの全てを網羅できるわけではありません。Core Web Vitalsの改善は重要ですが、最終的にはUX全体を最適化することが必要です。 本稿では、ページ読み込み時に「遅い」という印象をユーザーに与えないために筆者がよく用いるStreaming UIとそのプラ

本稿で扱うデータフェッチは高速なサーバー間通信を前提にしているため、バックエンドは細粒度なREST APIで設計することが最適だと考えます。 データフェッチの設計パターン 筆者の考えでは、データフェッチの設計は大きく2パターンに分けられます。データフェッチ層を設けるなどするような中央集権型の設計と、データフェッチコロケーションに代表される自律分散型の設計です。 中央集権型: 責務を集約し、一元管理を重視する 自律分散型: 責務を末端に分散し、自律性を重視する MetaやReactにおける自律分散型の設計の歴史については、筆者の前回の記事で詳細に解説しています。興味のある方はご参照ください。 解説 冒頭で触れたように、Metaでは自律分散型の設計が重視されており、特に大規模開発の保守性において重要だと考えられています。データフェッチ層を設けるような中央集権型の設計はなぜ好まれないのでしょう？

Reactはシンプルなサイトから複雑なアプリケーションまで、非常に幅広く採用されている人気のフレームワークです。OSS化から10年以上の歴史がありながら、昨今もReact Server Componentsなど革新的なアイディアを我々に提案し続けています。 一方で、React Server Componentsへの批判的意見やBoomer Fetching問題などを見ていると、Reactチームと一部Reactユーザーの間には意見の相違が見て取れます。この意見の相違はそれぞれが置かれた状況の違いから生じるもの、つまり「見てる世界が違う」ことに起因してると筆者は感じています。 本稿では「Reactチームの見てる世界」を歴史的経緯を踏まえながら考察し、Reactの根本にある思想やコンセプトに対する読者の理解を深めることを目指します。 要約 ReactはMetaの大規模開発を支えるべく開発され、シ

"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モジュールなど 任意の非同期

Next.js App Routerにおける設計やベストプラクティスを、筆者なりにまとめました。

先日、Next.jsの新たなレンダリングモデルであるPartial Pre-Rendering(以降PPR)について記事を投稿しました。 この記事を書いてる時は意識してなかったのですが、感想でアイランドアーキテクチャに言及されるケースが散見されました。社内で上記記事の話題になった時も同様に、アイランドアーキテクチャとの違いについて問われました。 結論から言うと、PPRとアイランドアーキテクチャは全く異なるものです。本稿ではPPRとアイランドアーキテクチャの違いについて解説します。 PPR まずはPPRとアイランドアーキテクチャの概要を改めて整理しましょう。 PPRはページをstatic renderingとしつつ、部分的にdynamic renderingにすることが可能なレンダリングモデルです。具体的には、画面をbuild時(もしくはrevalidate後)に静的生成しつつ、リクエスト毎

本稿はNext.js v15.0.0-rc.0時点の情報を元に執筆しており、PPRはさらにexperimentalな機能です。v15.0.0のリリース時や、PPRがstableな機能として提供される際には機能の一部が変更されてる可能性がありますので、ご注意下さい。 Partial Pre-Rendering(以降PPR)はNext.js v14.0で発表された、SSRやSSGにならぶ新たなレンダリングモデルです。 PPRは前述の通り開発中の機能で、v15のRC版にてexperimentalフラグを有効にすることで利用することができます。ppr: trueとすれば全部のページが対象となり、ppr: "incremental"とすればexport const experimental_ppr = trueを設定したRouteのみがPPRの対象となります。 // next.config.mjs

Next.js App Routerは巷では難しいと評されることが多々あります。これはReactの新機能であるServer ComponentsをはじめとするServer 1stとも言えるパラダイムシフトを必要とすること、そして初見殺しなデフォルトのキャッシュ挙動に起因していると筆者は考えています。 パラダイムシフトが必要となるServer ComponentsやServer ActionsなどのReactの新機能については、エラーで指摘・修正のヒントが提示されるなどの初学者のフォローもしっかり考慮した設計がなされてたり、多くのドキュメントや記事が公開されているので、これらについてはhooksが登場した時のようにあとは世の中に理解が広まるまでの時間の問題なのかなとも感じています。 一方でキャッシュについては、デフォルトで積極的かつ何層にも分けてキャッシュされる上、「意図せずキャッシュされて

Next.jsでSSRF（=Server Side Request Forgery）の脆弱性が発覚したことが社内で話題になったので、まとめておこうと思います。対象の脆弱性は以下です。 脆弱性の概要 SSRF脆弱性は本来到達できないサーバーに対して、公開されてるサーバーを経由してアクセスすることができてしまう脆弱性です。 今回のNext.jsの脆弱性はhttpヘッダーのHostを書き換えることで、self hostingなNext.jsサーバーから任意のhttpリクエストを送信できてしまうというものです。これは、外部には公開してない内部APIに対するリクエストも可能になるため、SSRF攻撃になりえます。 今回の脆弱性の対象は、以下の条件を満たしている必要があります。 Next.jsをself hostingで運用している Next.jsアプリケーションがServer Actionsを利用して

この記事はlocation-stateをconformに対応させるために開発した、@location-state/conformの紹介記事です。 location-stateとは location-stateは履歴位置に同期する状態管理ライブラリです。主にNext.jsをサポートしています。 Next.jsなどを採用している場合、ページ内のuseStateは遷移時のunmountで状態が破棄され、ブラウザバック時には復元されません。そのため、アコーディオンやform要素の状態はブラウザバック時にはリセットされてしまいます。これはNext.jsに限らず、ReactやVueなどをベースにしたモダンなフロントエンドフレームワークを採用して、クライアントサイドルーティングが発生する場合に起きがちな挙動です。クライアントサイドルーティングが不在なMPAでは、bfcacheやブラウザ側の復元処理によっ

GitHub Copilot、みなさん使ってますか？すでに多くの方が利用しており、「ないと困る」という方から「提案の質に問題がある」「まだまだ使えない」という方まで、様々な意見を聞きます。 筆者はGitHub Copilotに対して非常にポイティブな立場です。GitHub Copilotは使い方次第で開発速度を格段に向上させることを身をもって体験しており、これからの時代においてはGitHub CopilotなどのAIツールを使いこなせるかどうかで、個人の開発速度に非常に大きな差が出ると考えています。 重要なのは使い方次第と言う点です。前述のように様々な感想が溢れているのはAIツールの習熟度が大きく影響しているようにも感じます。AIツールは静的解析同様、利用者側の手腕が大きく問われるツールであると筆者は感じています。コマンドプロンプトエンジニアリングという言葉もあるように、AIツールを使いこ

以前、Next.jsの遷移の実装やRouter Cacheの実装について筆者が調べたことを記事にしました。 本稿はこれらの記事同様に、revalidatePath/revalidateTagの仕組みについて筆者が興味のままにNext.jsの実装を調査したことについてまとめたものになります。直接的にApp Routerを利用する開発者に役立つかどうかは分かりませんが、ある程度裏側でこういうことが起きてるんだという参考になれば幸いです。 前提条件 App Routerの機能であるrevalidatePath/revalidateTagについて触れるため、以下の機能について理解してる必要があります。本稿ではこれらの機能について改めて詳解しないので、必要に応じて各ドキュメントをご参照ください。 Caching Router Cache Data Cache Full Route Cache rev

conformはプログレッシブ・エンハンスメントを意識して作られたReactのformライブラリです。 RemixやNext.jsなどのフレームワークをサポートしています。react-hook-formのServer Actions対応は現状検証段階なのですが、conformはすでにServer Actionsにも対応しています。 本稿ではNext.js(App Router)におけるconformの使い方を中心に紹介します。 Server Actions もう散々他の記事や公式ドキュメントで紹介されていますが、簡単にServer Actionsについて復習します。 基本的な使い方 Server Actionsはクライアントサイドから呼び出すことができる、サーバー側で実行される関数です。 この機能の最も一般的なユースケースは、サーバー側のデータを変更する際に呼び出すことです。ReactはJ

Next.jsアプリケーションのデプロイ先としてVercelはとても利便性が高く、優れたプラットフォームです。一方で、インフラ的な都合やコスト的な都合でSelf-hosting、つまりVercel以外を利用したいケースはそれなりに多いのではないでしょうか。実際、筆者の周りではSelf-hostingでNext.jsを利用しているケースは多く見受けられます。Next.jsはVercel非依存なOSSと銘打ってますが、実際にはNext.jsに必要なインフラ仕様をVercelが隠蔽しているため、Self-hostingでNext.jsを利用するには制約があったり高い理解が求められがちです。昨今、App Routerの登場とその強力なキャッシュ戦略により、Vercel以外でNext.jsを扱うことはより難しくなってきました。 一方で、Self-hosting向けのドキュメントや対応は少しづつですが

テストを書いてないというチームには色々理由があると思いますが、「何をテストすべきかわからない」「書き方がわからない」「どのくらいメリットがあるかわからない」という意見は多いのではないでしょうか？テスティングフレームワークの選定や使い方を学ぶのは重要ですが、それ以上にテストの目的や戦略を学ぶことが重要です。チーム開発においてテストを活かすのは相応の知識とスキルが必要になりますが、活かせればテストは開発スピードを維持・促進する飛び道具になり得ます。 本稿は筆者が取り組んで実際に高いチーム満足度と速度を得られた、テスト戦略についてまとめたものです。

先日、location-stateというパッケージについての記事を公開しました。 履歴に基づいて状態を復元できるReact系ライブラリで、現在はNext.jsを重点的にサポートしています。このライブラリの構成はcoreとなる部分とNext.js依存な部分を切り離しscoped packageとし、内部構成もこれに合わせていわゆるmonorepo構成で開発を行なっています。 @location-state/core: coreとなる部分 @location-state/next: Next.js依存な部分 この記事では、monorepoのパッケージ開発を快適にするために実際に採用したツールを紹介していきます。本稿で紹介するツールは以下になります。 pnpm turborepo tsup changesets Renovate pnpm まずパッケージマネージャーですが、個人的に最近はpnpm

この記事は最近リリースしたlocation-stateというライブラリの紹介記事です。 モチベーション Reactのstate管理は、様々な分類が可能です。筆者が過去に書いた記事「スコープとライフタイムで考えるReact State再考」では、stateの分類は大きく以下2つの観点で分類ができると述べました。 スコープによる分類 ライフタイム（=stateの生存期間）による分類 詳しく知りたい方はこの記事を読んでいただきたいのですが、今でもstate管理というと多くの場合スコープによる分類の話が多く、ライフタイムによる分類の話はあまり聞かない気がします。 なぜライフタイム観点が重要か ライフタイムを意識せずに実装した場合に発生するのが、遷移時に状態が破棄され復元されない、つまりブラウザバックでstateが壊れるという問題です。この問題については以下の記事で、Vercelの社長が2014年に

前回、App Routerの遷移の仕組みと実装についてまとめました。 今回はこれの続編として、App RouterのClient-side Cacheの仕様や実装についてまとめようと思います。まだドキュメントに記載のない仕様についても言及しているので、参考になる部分があれば幸いです。 App Routerのcache分類 App Routerは積極的にcacheを取り入れており、cacheは用途や段階に応じていくつかに分類することができます。まずはそのcacheの分類を確認してみましょう。 Request Deduping Request Dedupingはレンダリングツリー内で同一データのGETリクエストを行う際に、自動でまとめてくれる機能です。 nextjs.org/docsより デフォルトでサポートしているのはfetchのみですが、Reactが提供するcacheを利用することでDBア

Next.jsのv13.4が発表され、App RouterがStableになりました。App Routerは発表以来着実に実装が進んでおり、最近もServer ActionやParallel Routesなどの新機能が次々と発表されています。 当然ながらこれらの話題はフレームワーク利用者目線の話題が多いのですが、本稿はApp Routerがどう実装されているのか、筆者の興味のままに遷移処理周りを中心に調査したまとめ記事になります。知っておくと役に立つ点もあるかと思うので、参考になれば幸いです。 Next.jsの遷移とprefetch挙動 Next.jsの遷移を理解するには、まずprefetch挙動について知る必要があります。今回は調査用のデモとして、pagesとappそれぞれで同じようなページをいくつか用意しました。 pagesで実装したページ appで実装したページ これらで従来のpag

Reactと現実世界をつなぐescape hatches、そしてReact Server Components 最近、react.devがリリースされました。この新しい公式サイトは、hooks時代に適用した新たなドキュメントサイトであり、入門学習のためのドキュメントとAPIドキュメントを兼ねています。このサイトはかなり力が入ってて、見てるといろんな発見があります。 個人的には中でも、learnにあるEscape Hatchesの章に興味が惹かれました。本稿ではescape hatchesやReact Server Componentsを通してReactがデータフェッチをどう考えてきたのか、自分なりにまとめてみます。 Escape Hatches Reactは宣言的UIを実現するべく設計されており、複雑化しやすい状態管理やイベントリスナーを抽象化・制限するよう設計されています。一方で、現実の

reactでformを作る時、react-hook-formを使う方も多いと思います。react-hook-fomで実装すると、非制御コンポーネントベースなためレンダリングコストを減らすことが期待でき（実装にもよります）、また、zodとの連携によるバリデーション実装の容易さなど、実装や設計面においても多くのメリットが得られます。 一方で、チームでreact-hook-fomを使って実装を進めていくには設計的難しさを伴うことがあります。筆者は実際にform内におけるモーダルの実装で設計の見直しを迫られました。 本稿は実際に設計を見直すことで筆者が感じた、react-hook-fomの実装における設計の勘所の紹介記事になります。 2つのformの実装原則 先に結論です。react-hook-fomを使ったform実装においては以下の2つの原則を守ることが設計上重要になってきます。 form実装

本稿における「単体テスト」とは自動テストにおける単体テストを指します。手動テストのことではないので、ご了承ください。 単体テストの考え方/使い方という本を読みました。筆者自身、「単体テストはプロダクションコードの付属」という意識がどこかにありました。この本を読んで、単体テストについてあまりに何もわかってなかったことに気付かされ、単体テストの設計はプロダクションコードの設計と同じくらい重要という意識に変わりました。何のために単体テストをやるのか、いいテストとは、「単体」とは、など多くの点で学びを得られ、また、多くのプラクティスとアンチパターンを知ることができました。 本稿はこの本を読んで得られた学びを、フロントエンド開発、特にコンポーネント開発に適用することを試みた際のまとめです。より詳細な解説を求む方には本を手に取ってもらう前提で、できるだけポイントを抑えられるようにまとめることを目指しま

RecoilをReduxと同じ「グローバル状態管理ライブラリ」とまとめてしまうことに若干違和感があったので、自分なりに考えをまとめてみました。これらは何に対してグローバルなのか考えると、異なる特徴を持ったライブラリに思えるのです。 ReduxとRecoilの登場と背景 まずReduxやRecoilが登場した頃の課題感を、筆者なりにまとめてみます。 Redux Reduxの歴史は状態管理ライブラリの中では古く、2015年に初版が公開されました。ReduxはReactに依存してないので、他のViewライブラリやRedux単体でも採用可能でしたが、React・Reduxのセットは、フロントエンドに一貫した設計を設けることができるため高い人気を得ました。 筆者の主観ですが、Redux登場当時はReactの実装でバケツリレーをしないこと・複雑な状態を扱えることが多くのエンジニアの関心ごとだったように

以前、Next.jsのスクロール位置復元について記事を書きました。 上記記事でSPAとMPA(Multi Page Application)における、ブラウザバック/フォワード時のスクロール位置復元について言及しました。 MPAではスクロール位置がブラウザによって復元されることがある(ブラウザの実装に依存) SPAではこれらが軽視されがち Next.jsにおいても、デフォルトでは復元されない(ChromeでSSGページなど一部条件下では復元される) Next.jsではexperimental.scrollRestorationを有効にするとスクロール位置をsession storageに保存し復元する これらと同様に、ブラウザバック/フォワード時のUI復元についても軽視されがちなものの1つです。最近もこの手のUI体験の悪さについて、問題提起がされ話題になりました。 ブラウザバック/フォワー

脱稿(執筆の完了・提出)は当初6末予定だったのですが、書いてるうちにどうしても間に合わず2週間ほど予定をずらさせていただきました。実は企画が通る前から少し書いてたのですが、それでもどうしても子育て・仕事・執筆の3つを成り立たせ続けるのは至難の業で、結果遅れてしまいました。 企画後、実際の執筆の流れもみてみましょう。 1. 調査・構成の検討 企画時点である程度方針や構成概要は検討済みでしたが、一番はWebアプリ開発を通じてRustを学ぶ本なので「何をどこまでどうやって作るか」を検討しました。 Rustの文法についてはどこまで解説するのか、マルチスレッドやメモリ周りに触れすぎると読者は離れてしまわないか RustのWebフレームワークはいくつもあり、どれを使うのか SQL周りのライブラリは何を使うのか フロントエンドはどうするのか。Rustのフレームワークではテンプレートエンジンを使うパターン