Next.jsの考え方Next.js App Routerにおける設計やベストプラクティスを、筆者なりにまとめました。
PPRはアイランドアーキテクチャなのか
先日、Next.jsの新たなレンダリングモデルであるPartial Pre-Rendering(以降PPR)について記事を投稿しました。 この記事を書いてる時は意識してなかったのですが、感想でアイランドアーキテクチャに言及されるケースが散見されました。社内で上記記事の話題になった時も同様に、アイランドアーキテクチャとの違いについて問われました。 結論から言うと、PPRとアイランドアーキテクチャは全く異なるものです。本稿ではPPRとアイランドアーキテクチャの違いについて解説します。 PPR まずはPPRとアイランドアーキテクチャの概要を改めて整理しましょう。 PPRはページをstatic renderingとしつつ、部分的にdynamic renderingにすることが可能なレンダリングモデルです。具体的には、画面をbuild時(もしくはrevalidate後)に静的生成しつつ、リクエスト毎
PPR - pre-rendering新時代の到来とSSR/SSG論争の終焉
本稿は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 breaking change - disable router/fetch cache by default
Next.js App Routerは巷では難しいと評されることが多々あります。これはReactの新機能であるServer ComponentsをはじめとするServer 1stとも言えるパラダイムシフトを必要とすること、そして初見殺しなデフォルトのキャッシュ挙動に起因していると筆者は考えています。 パラダイムシフトが必要となるServer ComponentsやServer ActionsなどのReactの新機能については、エラーで指摘・修正のヒントが提示されるなどの初学者のフォローもしっかり考慮した設計がなされてたり、多くのドキュメントや記事が公開されているので、これらについてはhooksが登場した時のようにあとは世の中に理解が広まるまでの時間の問題なのかなとも感じています。 一方でキャッシュについては、デフォルトで積極的かつ何層にも分けてキャッシュされる上、「意図せずキャッシュされて
Next.js App Router 知られざるClient-side Cacheの仕様
前回、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ア
フロントエンドにおける「単体テストの考え方/使い方」
本稿における「単体テスト」とは自動テストにおける単体テストを指します。手動テストのことではないので、ご了承ください。 単体テストの考え方/使い方という本を読みました。筆者自身、「単体テストはプロダクションコードの付属」という意識がどこかにありました。この本を読んで、単体テストについてあまりに何もわかってなかったことに気付かされ、単体テストの設計はプロダクションコードの設計と同じくらい重要という意識に変わりました。何のために単体テストをやるのか、いいテストとは、「単体」とは、など多くの点で学びを得られ、また、多くのプラクティスとアンチパターンを知ることができました。 本稿はこの本を読んで得られた学びを、フロントエンド開発、特にコンポーネント開発に適用することを試みた際のまとめです。より詳細な解説を求む方には本を手に取ってもらう前提で、できるだけポイントを抑えられるようにまとめることを目指しま
ZennでRustの記事を書いたら本を書くことになった話
脱稿(執筆の完了・提出)は当初6末予定だったのですが、書いてるうちにどうしても間に合わず2週間ほど予定をずらさせていただきました。実は企画が通る前から少し書いてたのですが、それでもどうしても子育て・仕事・執筆の3つを成り立たせ続けるのは至難の業で、結果遅れてしまいました。 企画後、実際の執筆の流れもみてみましょう。 1. 調査・構成の検討 企画時点である程度方針や構成概要は検討済みでしたが、一番はWebアプリ開発を通じてRustを学ぶ本なので「何をどこまでどうやって作るか」を検討しました。 Rustの文法についてはどこまで解説するのか、マルチスレッドやメモリ周りに触れすぎると読者は離れてしまわないか RustのWebフレームワークはいくつもあり、どれを使うのか SQL周りのライブラリは何を使うのか フロントエンドはどうするのか。Rustのフレームワークではテンプレートエンジンを使うパターン
Next.jsはどうやってスクロール位置を復元するのか
Next.jsにはexperimental(実験的機能)でscrollRestorationというフラグが存在します。 // next.config.js const nextConfig = { // ... experimental: { scrollRestoration: true, }, } module.exports = nextConfig デフォルトでもブラウザ側でスクロール位置を復元してくれることもありますが、Safariでは復元されなかったり、ChromeでもgetServerSideProps利用時にはこのフラグを有効にしないとスクロール位置が復元されないなど不安定な状態です。最近この辺りについて識者の方々から色々ご教示いただき、自分では気付けないような部分の知見も多く得られたので、備忘録兼ねてscrollRestorationが何を解決しようとして、どう実装されて
スコープとライフタイムで考えるReact State再考
ReactはじめSPAのStateは大きく2種類、Local State・Global Stateの2種類でおおよそのStateの分類が可能であると考えていました。これに対し会社の先輩から意見をもらって、以下2点に気づきました。 Global Stateには大きく、Client StateとServer Stateの2つがある Stateにはライフタイム（生存期間）が存在し、Client Stateにはスコープ的Globalと時間的Globalの2つが含まれている これらを意識すると、自分はStateの実装を結構感覚的にやってしまっていたなと気づいたので、Stateの分類について改めてまとめてみようと思います。Reactで何かしらのStateを実装する時に、本稿の分類が実装の参考になれば幸いです。 スコープによるStateの分類 まずこれまで自分が認識してたスコープにおけるStateの分類
似て非なるCSS Module Scripts
昨年くらいからNext.jsの影響もあり、CSS Modulesの人気がまた高まってるように感じますね。State of CSSのCSS-in-JSランキングでも満足度、興味、利用率、認知度などどれをとっても1~2位に入ってました。 CSS Moduels自体はReactのJSXなどと同様、JSを拡張し利用できる技術です。しかし、このアプローチを有用と思った人たちが「JSやブラウザの仕様としてCSSをimportできたらいいのにね」と思いChromeに実装されつつあるのが「CSS Module Scripts」です。 仕様になったならいい話じゃん！で終わればいいんですが、なんとこの「CSS Module Scripts」、「CSS Modules」と仕様が違うんですね。現状まだwebpackでは「CSS Module Scripts」は未サポートですが、今後サポートするつもりっぽいのでこの
晩年のIEに思いを馳せる
昨年くらいから多くのプロダクトでIE11のサポート終了が盛んになり、今年はIE11自体がサポートを来年終了することを発表したり、Google検索のIEサポート終了があったり、1つ大きな時代の節目のようなものを感じる1年でした。 IEは最盛期は95%近くのシェアを占めていたそうですが、2021/10時点のデータではIEのシェアはPCで4%程度とやはりだいぶシェアも落ちてきた印象もあるし、そもそも昨今はスマホブラウザの流入が多いプロダクトなんかではIE対応自体ほとんどやってなかったという方も多いのかもしれません。 僕は昔IE7までは対応したことがあり、当時の感覚で言うとIE11って相当バグや特殊な仕様が少ない方だったイメージだったのですが、下記のIEサポートを終了すると使える機能一覧を見るとやはり数年の進化の差は大きくすでにだいぶ取り残されてる状態だったのだなと思います。 一方、「Safari
全ての道はRomeへ続くのか - これからのJavascript開発を考える
Romeとは 現代のJavascript開発には多くのツールチェーンが必要とされます。Babel,webpack,Jest,ESLint,Prettier,Typescriptなどを組み合わせて開発することが多く、さらにこれらの一部代替選としてesbuild,SWC,Viteなどのツールチェーンの選択肢が存在し、選択肢の多さやその組み合わせの複雑さに苦い思いをしたことがある方も少なくないのではないと思います。 こうした中で、新たに開発が進められているツールチェーン、Romeをご存知でしょうか？ Romeは先に挙げたように複数のツールチェーンを役割ごとに組み合わせて使うのではなく、1つのツールチェーンでこれら全ての役割を担ってしまおうという壮大な計画を持つツールチェーンです。 Romeは2020/03にFacebookより発表されました。現在は法人化され、yarnやBabelの生みの親である
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
