はてなブックマーク

サンプルリポジトリ 実行確認 ServerComponents に疲れていませんか？ Next.js のバージョン 15 のリリースを迎えた昨今 AppRouter を中心に据えられるようになり、SSR を行うには ServerComponents が避けて通れません。しかし Pages Router を使っていた頃と比べると、大きく使い勝手が変わってしまったため、この変更に対応する対処に疲れてはいないでしょうか？ということで、余計なことを考えずに簡単に SSR を行う方法を紹介します。 作るのは ClientComponent のみで OK 非同期データの取得に ServerComponents の構造を必要としないため、全てを問答無用で Client Component にして問題ありません。 作り方 React 標準機能で SSR させる next-ssr パッケージを使用します。素

Prisma Accelerate の Self Hosting の必要性 Prisma Client でクエリを作ると、Prisma Engine を介して、各 DB に対応した SQL に変換されます。Prisma Engine は Rust で記述されており、環境ごとにバイナリが用意されています。しかし Cloudflare Workers/Pages や Vercel Edge Functions、Deno などではネイティブのバイナリが使用できないため、WebAssembly 版の Prisma Engine が提供されています。ただ、WebAssembly 版はサイズが大きく、900KB 程度あります。Cloudflare Workers/Pages の無料版や Vercel Edge Functions では 1MB というサイズ制限があるため、その他のコードと合わせてデプロ

無料枠のリクエスト数は Deno Deploy が月単位で、Cloudflare Workers が日単位です。どちらも普通に使うには十分な数が用意されています。ちなみに Vercel で画像最適化をやると無料枠は 1000/月です。 CPU に関しては、Cloudflare の 10ms はけっこうキツイです。2K 解像度をを Webp に変換しようとすると、かなりの確率で失敗します。デジカメで撮った写真をそのままアップロードしているようなケースでは問題が発生します。 サイズに関しては、プログラムコードを圧縮したときの値です。Deno Deploy は特に制限がないようです。Cloudflare の 1MB は、普通のコードなら何の問題もないのですが、画像変換に関しては wasm を使うことになるためそれなりにタイトです。そのため Workers 用の画像変換ライブラリには avif エ

開発時の実行方法によってランタイム環境が異なるため、インポートするパッケージを変えなければなりません。 実行環境によるインポートファイルの切り替え インポートの切り替えは Vite の機能を使えば簡単に行えます。 vite でエイリアスを仕込む vite.config.ts NODE_ENV に応じて、インポート時のコードが切り替わるようにします。 import { vitePlugin as remix, cloudflareDevProxyVitePlugin as remixCloudflareDevProxy, } from "@remix-run/dev"; import { defineConfig } from "vite"; import tsconfigPaths from "vite-tsconfig-paths"; import path from "path"; e

React の SSR にフレームワークの機能は必要ない React で SSR を行う際、フレームワークの機能を使わずに React の標準機能だけで実現する方法を紹介します。Next.js でも同じ方法が有効なので、これを使えば Remix への依存が本当の意味で最小になります。 Remix での一般的な方法だと SSR を行う場合、routes 直下のファイルで実装した loader 関数を使ってデータを作成し、各コンポーネント内の useLoaderData データを受け取ります。この方法だと、ページの頭でどんなデータを取得するかを決めなければならず、コンポーネントの状態に合わせて柔軟にデータを用意することが困難です。 実はそんな方法を使わずとも React には、コンポーネント側でデータを取得する機能が用意されています。もちろん React の利点を殺す ServerCompon

Edge Runtime 上での Prisma Accelerate の必要性 Prisma を Edge-Runtime という制限された環境で使う場合、DB へクエリを発行する機能を持った PrismaEngine を直接動かすことが出来ません。これは PrismaEngine が Rust で書かれているためです。いずれは対応される可能性はありますが、現時点では動きません。このため、Edge-runtime 上で Prisma を使う場合は、PrismaEngine を切り離した状態で使う必要があります。 ここで登場するのが Prisma Accelerate という Prisma の公式サービスです。このサービスを使うと、PrismaClient 上で呼び出したクエリは、一旦 JsonProtocol に変換され、手元の PrismaEngine をスルーして、Prisma Acc

画像の最適化の場合、1600*1600 ぐらいの画像を変換すると高確率で CPU 制限に引っかかります。また、外部サービスを呼び出すようなコードを書いた場合、並列アクセス時にデッドロックしないように気をつける必要があります。 また、Worker サイズはバックエンドで動く JavaScript や wasm を圧縮したときのサイズです。Pages で Assets として配るファイルは計算に入れません。このサイズがどうにもならない時は、Worker を分離するしかありません。 必要な機能 画像最適化機能 別になくても困らないのですが、あったほうがページが軽くなるので推奨事項です。Cloudflare には有料での画像最適化サービスがありますが、無料というのが大前提なので却下です。 画像変換は自分で作らなくともライブラリが世の中に一通り揃っています。その手のライブラリ類はほとんどが C 言語

Cloudflare Workers の無料プランで画像を圧縮する Next.js のプロジェクトを Cloudflare にデプロイする場合、問題になるのが Vercel が提供している画像の自動圧縮機能です。これを Cloudflare でも実現するためには、Cloudflare Workers が使えそうですが、無料プランでは画像の圧縮機能を提供していません。意地でも無料で実現したいという乞食精神に乗っ取り、画像変換コードを書くことにしました。 画像の変換方法 Cloudflare Workers では、一度のリクエストで処理できる CPU 時間は 10ms です。非同期アクセスの待ち時間は含まれないので、純粋な処理時間です。高速に処理するのならネイティブコードを使うのが一番ですが、もちろん使えません。そこで、WebAssembly を使うことにしました。最近 WebAssembly

サンプルコード GitHub https://github.com/SoraKumo001/next-syncexternalstore Vercel https://next-syncexternalstore.vercel.app/ あまり話題にされない useSyncExternalStore ReactHooks 解説系の記事で無かったことにされたり、一瞬だけ概要が紹介されるだけなことが多い useSyncExternalStore です。可哀想なので、オレオレ State ライブラリを作って使い方を紹介したいと思います。 ちなみに useSyncExternalStore を使うと、こちらの記事で使っているようなライブラリも簡単に作れます。 オレオレ State ライブラリは一瞬で構築できる import { useRef, useSyncExternalStore } from

JavaScript の forEach で async/await は使える JavaScrript の forEach で async/await が使えないという誤解が一部あるようですが、全く問題なく使えます。そういう誤解が何故発生してしまうかと言えば、非同期を同期させるための管理を行っていないからです。プログラムは思った通りではなく書いたとおりに動きます。同期させるようにプログラムを書かなければ、その通りの結果が返ってきます。使えないのではなく使っていないのが原因です。 forEach で非同期を同期させるプログラムを作る 配列の内容を 1 秒ごとに一つ表示させるプログラムを forEach で作ってみます。 こちらに実行環境を用意しました プログラム内容 // 疑似セマフォによるスケジューラ const semaphore = ( limit = 1, count = 0, rs

Storybook のインタラクションテストのコストを下げる Storybook を使用すると、ブラウザ上で動作を確認しながらテストコードを記述できるため、生の Jest よりも開発が容易になります。ただし、Storybook には Jest にある重要な機能である jest.mock がないという欠点があります。jest.mock は、テスト対象のコンポーネントがインポートしているモジュールをフックして、簡単にモックを作成することができますが、Storybook ではこの機能は使用できません。ビルド時に他のファイルへの干渉が防止されてしまいます。 この問題を解決するために、以下の Addon を使用することで、jest.mock と同じような機能を Storybook 上で利用することができます。 npm サンプルプログラム 動作内容 ログイン用フォームの動作チェック FormMock.

極限まで簡単に SSR を実装する流れ 不要な既存機能 今回の内容を実装するに当たってgetServerSideProps、getInitialProps、React Server Componentsは必要ありません。特殊なものを仕込んだりはしないのでnext.config.jsの設定も不要です。_app.tsx に何か書く必要もありません。 非同期データがコンポーネント上で簡単に SSR で出力可能 非同期データを扱う最小限のサンプルコードです。コンポーネント上で非同期の'Hello world!'を返していますが、きちんと初期レンダリングで HTML 上に出力されています。もちろん fetch で取得したデータも利用出来ますが、そちらは後ほど紹介します。 src/pages/simple.tsx 非同期データが必要なコンポーネントを<SSRProvider>で囲み、データが必要なとこ

１．フロントテストと Storybook の活用 フロントテストのどこにコストがかかるのか バックエンドのテストはシンプルな入力と出力が多いので、テスト作成は比較的簡単です。一方、フロントエンドのテストは UI イベントや動的な要素も含まれ、複数の出力があるため、テスト作成はより複雑になります。これにより、テスト作成のコストが増大します。 生 jest で書くフロントテストと心の目 Jest は主に JavaScript のユニットテストをサポートするツールであり、UI レンダリングのテストを行うためには対応するライブラリが必要です。Jest は DOM イベントをエミュレートすることはできますが、ユーザーの操作と同様のインタラクションを再現することは困難です。機能の多いコンポーネントをテストする際に、Jest を使用するとテストコードが複雑になりがちです。そして最大の問題は、視覚的な部分

Next.js の SSR は面倒くさい SSR を考えない場合、外部から取ってきた非同期データのレンダリングは、コンポーネント内に取得処理を置いて、受け取れた時点でデータを表示という流れで比較的簡単に記述できます。しかし SSR で初期 HTML に非同期データを加えようと思うと、一気に面倒になります。 何故面倒なのかと言えば、Next.js の初期レンダリングは非同期に対応していなかったからです。そのため、一般的な方法で SSR をやろうとするとgetInitialPropsやgetServerSidePropsを使って非同期データを収集し、コンポーネントにデータを引き渡す流れになります。 この構成の問題点は、クライアントで再フェッチが必要になったときに、サーバ側とクライアント側で別々に処理を書かなければならないことです。 実は可能になっていたコンポーネント側からの SSR データ作成

サンプルソース https://github.com/SoraKumo001/next-apollo-ssr 1. @apollo/client の useSuspenseQuery に関して 2022/12/10 の 3.8.0-alpha.0 から使えるようになった新機能で、GraphQL の query が Suspense 対応になったものです。Alpha 版でも実験的な扱いになっており、インポートする際はuseSuspenseQuery_experimentalという名前になっています。 具体的な実装状態は以下を参照してください 2. Suspense と SSR と ServerComponents Suspense を前提とする fetch 内包 hook をサーバ上で使用する上での注意点があります。サーバー側で Promise を Suspense で待つと、初期 HTML

SuspenseとSSR動作に関して React18.3以降の新機能useを使うと、throw promiseとデータの取得部分の処理が簡略化出来ます。そしてuseを使ったコンポーネントは非同期中の状態を受け取るためSuspenseとセットで使われることが想定されます。しかしNext.jsで使う場合、必ずしもセットにしなくても動作します。その場合は異なった挙動をするので、違いを確認するためNext.js 13の新機能app/ Directory (beta)を使って出力結果を検証します。ちなみにReact 18.2やNext.js 12以前のバージョンでも同様の動作をします。最新版で固めたのは、新機能が非同期に最適化されているため、コードの記述量が減るからです。 Next.jsの初期設定 インストールするパッケージ TypeScriptや@types/nodeは自動で入ります。

0. 今回作ったもの Demo npm に登録したもの 1. 地獄への道、その扉を開くまで 1.1. Markdown エディタの種類 一般的な Markdown エディタには、おおよそ以下のような二種類が存在しています。 1 ペイン系 入力テキストそのものに装飾をかける Zenn で使われている方式 2 ペイン系 テキストとレンダリング結果を左右などに分けてそれぞれ表示する Qiita などで使われている方式 どちらが高度な技術を要するかといえば圧倒的に 1 ペイン系です。そもそも Web アプリケーションで入力中テキストをリアルタイム装飾するのは、洒落にならない労力が必要です。 1.2. ワンペイン Markdown エディタを組み込む方法 選択肢はSimpleMDEとその改良版のEasyMDE、そしてそれを React で利用する場合はReactSimpleMDEがセオリーとなってい

formやinputを非制御で最も簡単に使う方法 useStateやuseRefを使わずに、最小限の記述でフォームに入力したデータをとることが出来ます Reactの公式ではvalueプロパティを使って制御する形を推奨しています しかしvalueに対応するsetStateが上位の層にいると、テキストを入力するごとに下位コンポーネントの再評価が行われ重力地獄に落ちることがあるので、特段の理由が無ければ私は非制御を推奨します 重力地獄はmemo化で対処は出来るといえば出来るのですが、それなら最初から余計な動きをさせないのが一番です また、リアルタイムなバリデーションチェックはsetStateに関係なく、onChangeイベントで入力内容のチェックが可能です const Form = ({ onSubmit }: { onSubmit: (value: string) => void }) =>

JavaScript の forEach は非同期ではない 時々ネットの解説記事で forEach は非同期だという解説を見かけますがこれは間違っています。実際の処理は逐次関数をコールバックしていくだけなので、普通に同期で動いています。コールバック中に非同期処理を使って待機動作を行っていないので、バラバラに動いているように見えるだけなのです。 検証用の非同期処理を作成 ランダムに 1000ms 以内の時間を待機して文字列を出力する関数です。TypeScript になっているので、JavaScript で実行したい場合は型定義を外してください。 const f = (value: string) => { return new Promise<void>((resolve) => setTimeout(() => { console.log(value); resolve(); }, Mat

ContextAPI と useState は本来組み合わせてはいけない ContextAPI の機能は、コンポーネントの階層を飛び越えてデータを配信することにあります。しかしここで気をつけなければならないのが、Provider に設定する値を useState で管理すると、Provider を持っているツリーが全て再レンダリングされることです。この書き方は最悪のアンチパターンです。 アンチパターン Provider に渡す値を更新をするのに上位のコンポーネントの useState のディスパッチャーが使用しています。どれか一つでも値を更新すると、全てのコンポーネントが再レンダリングされます。ContextAPI での解説などでこの方法をよく見かけます。しかし値一つの変更で全てを再レンダリングするなら、状態管理の必要性そのものが無くなってしまいます。これはやってはならない書き方です。 i

まずは各コンポーネントの特性について説明します 通常コンポーネント いつも利用しているコンポーネント Server や Client コンポーネントの配下に置くと、その特性を引き継ぐ Streaming で直接使うと非同期で生成したデータが props として渡せないので、HTML として一瞬表示されるものの、その後すぐデータが消えた状態となる Server コンポーネント *.server.js というファイル名で作られるコンポーネント サーバ側でレンダリング クライアントに渡されるときは HTML にレンダリングされ、コンポーネントとして再マウントされない コンポーネントの状態にならないので、クライアントから操作することは出来ない Client コンポーネント *.client.js というファイル名で作られるコンポーネント サーバとクライアント両方でレンダリングされる 通常コンポーネ

１．getInitialPropsの終焉 1.1. Next.jsではgetInitialPropsのSSRが終わったことにされている Next.jsの9.3以降、getStaticPropsやgetServerSidePropsが登場し、現在ではgetInitialPropsを使ったSSRが終焉を迎えたかのような風潮となっています。しかしgetStaticPropsとgetServerSidePropsは、実際の所で大きな欠点を抱えています。 getStaticPropsはSSG前提で使うなら全く問題ありません。しかし、ある程度の更新頻度をもつシステムやリアルタイムな編集機能と相性が悪いです。ISRで使う場合も有効期限後の一回目で古いデータが表示される仕様があるので、タイミングが悪いと、せっかっく訪れた人に古いデータを渡してしまうことがあります。使いどころによっては強力ですが、用途は限定

memo化について Reactのコンポーネントをmemo化するとき、再レンダリングを防ぐという記述を見かけることがあります。それは誤解であり、実際にmemo化で出来るのは以下のようになものです。 関数の再評価(ロジックの再実行)は防げる 仮想DOMの差分比較は防げない 最終的なレンダリングは確定した仮想DOMの状態次第なので、memo化に関係なく差分があるかどうかでDOM操作が決定する Reactは仮想DOMの値に変化があった場合に、DOMを書き換える構造になっています。memo化は仮想DOMの生成結果をキャッシュしているに過ぎません。親コンポーネントが再評価されれば、子コンポーネントはmemo化の可否に関わらず差分比較の対象です。 簡単な例 ソースコード import React, { memo, useState } from 'react'; const Test1 = memo((

※ こちらでも同じ記事を書いています 汎用的な型変換の必要性 TypeScriptで型を扱っていると、与えられたデータ構造に対して組み替えをかけ、新たな構造を作成し値を返す必要が生じます。これが不変の構造ならばもちろん都度、手動で定義しても問題はありません。しかしAPI作成時、ツールで自動生成されるような型に対応するのは大変な労力です。こういう場合に汎用的な型構造を作ることが出来れば、自動生成された型に対して、自動で対応可能です。今回はそういった時のための型定義の定石を紹介します GenericsとType typeの一般的な使い方は知っている物として話を進めます。TypeでGenericsを使い、extendsで型の変換を行う場合は以下のような書き方になります type タイプ名<型変数 extends 制約,...> = 型変数 extends 条件 ? 真の型 : 偽の型 =より前の