準備

必要なもの：コンピュータ、USBドライブ（または任意の可搬型ストレージデバイス）、インターネット接続、基本的な情報検索スキル

• どのインストールイメージを使用する場合でも、オフライン版イメージであっても、インターネット接続を準備することをお勧めします。これにより、カーネルやツールの更新が確実に行えます。経験豊富な場合は、必要に応じて判断してください。
• Wi-Fiを使用する場合、ネットワーク名は英語にしてください。tty環境では非ASCII文字（日本語など）が表示できず、認識できないブロック文字として表示されます。
• 同一ディスクにデュアルブートを計画している場合、Arch Linux用に十分なディスク容量を確保してください。将来のソフトウェアインストールのために、少なくとも100GBを推奨します。また、EFIパーティションの容量が256MB以上であることを確認するか、追加のマウントポイントを作成してください。
• Windows 10のパーティションがBitLocker暗号化を有効にしているか確認してください。事前にリカバリーキーを取得し、電源設定の「高速スタートアップ」を無効にしてください！

操作前に、内容をよく読み、理解できない部分は検索して学習してください。慎重に操作し、定期的にバックアップを取ってください。データは貴重です。

インストールメディアの作成

1. Arch Linux公式ダウンロードページからのみインストールイメージをダウンロードしてください。Arch Linuxはローリングリリースディストリビューションであることに注意してください。
2. カーネルを自分でコンパイルしたい場合は、カーネル/従来のコンパイルを参照してください。
3. 公式のインストールイメージを使用する場合、Ventoyを使用してブータブルUSBを作成することをお勧めします。

基本インストール

1. Arch Linuxメディアからのブート

電源を切り、USBドライブを挿入して起動します。BIOSに入り、USBを起動デバイスとして選択し、最初のオプションを選んでEnterキーを押すと、Arch Linuxインストール環境に入ります。

2. UEFIの確認

systemctl stop reflector.service
# 自動ミラー更新を無効にします。地理的なネットワーク環境により問題が発生する可能性があるためです。

ls /sys/firmware/efi/efivars
# EFI変数が一覧表示された場合、UEFIモードで起動しています。2025年のほとんどのマシンはUEFIブートです。

3. ネットワーク設定

Arch Linuxのインストールにはインターネット接続が必要です。オフラインインストールはより複雑で、オフラインインストールを参照してください。

有線接続の場合、LANケーブルを接続し、インターフェースのLEDが点滅しているか確認してください。数秒待つと接続が確立します。

キャンパスネットワーク環境では、上位ルーターでの認証が必要な場合があります。nbtverifyプロジェクトを参照してください。

Wi-Fiの場合は、iwctlを使用して接続します。

lspci -k | grep Network
# 無線アダプターが動作しているか確認します。問題がない場合はこの手順をスキップできます。

カーネルが無線ドライバーをロードしているか確認します。

以下のような表示が期待されます：00:14.3 Network controller: Intel Corporation Wi-Fi 6 AX201 (rev 20)。

表示がない場合、無線接続が無効（blocked: yes）になっていないか確認します。

rfkill list
# 無線アダプターは通常wlan0と呼ばれます。

ip link set wlan0 up
# 「Operation not possible due to RF-kill」などのエラーが出た場合：
rfkill unblock wifi

# iwctlを使用してWi-Fiに接続
iwctl # 対話モードに入る
device list # 無線デバイス（例：wlan0）を一覧表示
station wlan0 scan # ネットワークをスキャン
station wlan0 get-networks # 利用可能なWi-Fiネットワークを一覧表示
station wlan0 connect wifi-name # ネットワークに接続。日本語名はサポートされません。パスワードを入力してEnter
exit # 接続成功後に終了

ping www.google.com # ネットワーク接続性をテスト

ネットワーク設定に問題がある場合、ネットワーク設定/無線を参照してください。

5. システムクロックの同期

timedatectl set-ntp true # システム時間をネットワーク時間と同期
timedatectl status # サービス状態を確認

6. ミラーリストの更新（日本国内の場合）

vim /etc/pacman.d/mirrorlist # ミラーリストを編集
Server = https://mirrors.cat.net/archlinux/$repo/os/$arch # 日本のミラー
Server = https://ftp.tsukuba.wide.ad.jp/Linux/archlinux/$repo/os/$arch # 筑波大学
Server = https://mirror.osbeck.com/archlinux/$repo/os/$arch # Osbeckミラー

7. Btrfsパーティションの作成

ディスク情報の確認

lsblk

現在のディスクのパーティション状況を表示します。Arch Linuxをインストールするターゲットディスクを慎重に確認してください。

ディスクの命名規則：

• SATAドライブ：sda、sdb、sdc … パーティション：sda1、sda2 など
• NVMeドライブ：nvme0n1、nvme1n1 … パーティション：nvme0n1p1、nvme0n1p2 など

この例ではSATAディスクを使用します。実際のディスクに応じて/dev/sdxを置き換えてください。

cfdisk /dev/sdx

使いやすいTUIパーティションインターフェースが表示されます。😄

パーティションの操作手順

1. Swapパーティションの作成

• 矢印キーでFree spaceを選択。
• [New]を押してEnter、サイズを入力（RAMの60%～100%を推奨）。
• [Type]を押し、Linux swapを選択。

2. ルートパーティションの作成（Btrfs用）

• 残りのFree spaceを選択し、[New]を押してEnter。
• サイズを入力（デフォルト：残りの全スペースを使用）。
• タイプはデフォルトのLinux filesystemのまま。

3. パーティションテーブルの書き込み

• [Write]を選択し、yesを入力してEnter。

  ⚠️ 注意：書き込みを行わないと、変更は反映されません！

パーティションのフォーマット

ディスクの再確認

fdisk -l

EFIパーティションのフォーマット（新規作成の場合）

mkfs.fat -F32 /dev/sdxn

💡 デュアルブートの場合、WindowsのEFIパーティションを再利用可能で、フォーマットは不要ですが、十分な空き容量を確認してください。詳細はWindowsとのデュアルブートを参照。

Swapパーティションのフォーマット

mkswap /dev/sdxn

Btrfsパーティションのフォーマット

mkfs.btrfs -L myArch /dev/sdxn

Btrfsサブボリュームの作成とマウント

mount -t btrfs -o compress=zstd /dev/sdxn /mnt

# サブボリュームの作成
btrfs subvolume create /mnt/@        # ルートサブボリューム
btrfs subvolume create /mnt/@home    # /homeサブボリューム

umount /mnt

⚠️ 最終確認

• コマンドと操作を再確認してください！
• 誤操作はデータ損失、特にWindowsパーティションの誤削除を引き起こす可能性があります 😥。

8. パーティションのマウント（ルートから順に）

mount -t btrfs -o subvol=/@,compress=zstd /dev/sdxn /mnt # /ディレクトリをマウント
mkdir /mnt/home # /homeディレクトリを作成
mount -t btrfs -o subvol=/@home,compress=zstd /dev/sdxn /mnt/home # /homeディレクトリをマウント
mkdir -p /mnt/boot # /bootディレクトリを作成
mount /dev/sdxn /mnt/boot # /bootディレクトリをマウント
swapon /dev/sdxn # スワップパーティションを有効化

df -h # マウントを確認
free -h # スワップパーティションのマウントを確認

9. システムのインストール

pacstrap /mnt base base-devel linux linux-firmware btrfs-progs
# Btrfsを使用する場合、btrfs-progsパッケージを追加でインストール

pacman -S archlinux-keyring
# GPGキーエラーが出た場合、イメージが最新でない可能性があります。archlinux-keyringを更新して解決。

pacstrap /mnt networkmanager vim sudo zsh zsh-completions
# pacstrapスクリプトで必要な機能パッケージをインストール

10. fstabファイルの生成

現在のマウント状況に基づいて、ディスクパーティションを定義するfstabを生成。

genfstab -U /mnt > /mnt/etc/fstab

11. 新しいシステムに入る

arch-chroot /mnt
# コードハイライトが消えた？心配無用、chrootに成功しています！

12. ホスト名とタイムゾーンの設定

vim /etc/hostname
# マシンに名前を付けてください（特殊文字やスペースは避けてください。問題が発生する可能性があります。ホスト名を設定しないと、一部のGUIアプリが予期せず終了することがあります）。

vim /etc/hosts
# hostsファイルを編集

以下の内容を入力（myarchをあなたのホスト名に置き換え、間隔はタブで揃えます）：

127.0.0.1   localhost
::1         localhost
127.0.1.1   myarch.localdomain  myarch

ln -sf /usr/share/zoneinfo/Asia/Tokyo /etc/localtime
# 東京タイムゾーンにシンボリックリンクを作成

ls /usr/share/zoneinfo/
# 使用可能なタイムゾーンを確認し、必要に応じて上記コマンドのタイムゾーンを変更

13. ハードウェアクロックの設定

hwclock --systohc
# システム時間をハードウェアクロックに同期

14. ロケールの設定

vim /etc/locale.gen
# /etc/locale.genを編集し、en_US.UTF-8 UTF-8とja_JP.UTF-8 UTF-8の行頭のコメント（#）を解除
# このステップでソフトウェアの言語と文字セットを決定

locale-gen
# ロケールを生成

echo 'LANG=en_US.UTF-8' > /etc/locale.conf
# locale.confを設定。日本語ロケールはttyで文字化けする可能性があるため推奨しません

15. rootパスワードの設定

passwd root
# パスワード入力は非表示です。キーボードの不具合ではありません！😄

16. マイクロコードのインストール

pacman -S intel-ucode # Intel CPU用
pacman -S amd-ucode # AMD CPU用

17. Grubブートローダーのインストール

pacman -S grub efibootmgr os-prober
# grubはブートローダー、efibootmgrはNVRAMにブートエントリを書き込むために使用、os-proberはWindows 10の検出用

grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=ARCH
# EFIパーティションにgrubをインストール

vim /etc/default/grub
# ブートパラメータを編集

# "loglevel=3 quiet"を"loglevel=5 nowatchdog"に変更
# ファイル末尾に以下を追加：GRUB_DISABLE_OS_PROBER=false

• GRUB_CMDLINE_LINUX_DEFAULTのquietパラメータを削除。
• loglevelを3から5に変更して、エラー時のデバッグを容易に。
• nowatchdogを追加して、起動/シャットダウンの速度を向上。
• os-proberを有効にしてWindows 10を検出。

grub-mkconfig -o /boot/grub/grub.cfg
# grubの設定ファイルを生成
# Windows 10が検出された場合、「Found Windows Boot Manager on /dev/nvme0n1p1@/EFI/Microsoft/Boot/bootmgfw.efi done」のような出力が表示されます
# Windowsが別のディスクにある場合、出力されないことがあります。システムに入った後、再マウントしてこのコマンドを再実行してください。

全パラメータの詳細はArch Wikiを参照。

18. インストールの完了

exit # インストール環境に戻る
umount -R /mnt # 新しいパーティションをアンマウント
reboot # 再起動

再起動後、rootアカウントでログイン。

systemctl enable --now NetworkManager # NetworkManagerサービスを有効化し即時起動
ping www.google.com # ネットワーク接続性をテスト

Wi-Fiの場合：

nmcli dev wifi list # 近くのWi-Fiネットワークを表示
nmcli dev wifi connect "Wi-Fi SSID" password "ネットワークパスワード" # 指定のWi-Fiネットワークに接続

nmtui
# nmtuiの方が使いやすいですよ！😄

pacman -S fastfetch
fastfetch
# fastfetchをインストールしてシステム情報を確認
# 伝統的なneofetchの時間です！😄

shutdown 0
shutdown -h now
poweroff
# 上記3つのコマンドはいずれもシャットダウンです。😄 電源ポリシーがまだ設定されていないので、きちんとシャットダウンしてください。

おめでとう 🎉

これで、グラフィカルインターフェースなしの基本的なArch Linuxのインストールが完了しました！

グラフィカルインターフェースのガイドは次回の更新で公開予定ですが、いつものように：マニュアルをよく読んでください！

このガイドはきっかけに過ぎません。より多くの技術愛好者がコミュニティに参加してくれることを願っています！

関連リンク：NBTCA

• 📧 NBTCAメール：contact@nbtca.com
• 🌐 NBTCA GitHub：https://github.com/nbtca

サーバーサイドレンダリング（SSR）は、Web アプリケーションの「初期画面の読み込み速度」（FCP）を大きく改善します。ブラウザは完全な HTML コンテンツを直接受け取ってすぐにレンダリングするため、ユーザーはページ内容を素早く確認でき、SEO と体感性能のどちらにも有利です。

しかし、この時点のページは「静的な殻」にすぎません。読み込みが完了したように見えても、ボタンのクリックや入力欄の操作には何の反応もありません。この静的なページに「命」を吹き込むために必要なプロセスが Hydration（ハイドレーション／活性化）です。

2. Hydration とは？

Hydration とは、クライアント側の JavaScript フレームワークが、サーバーでレンダリングされた静的 HTML を「引き継ぐ」プロセスです。

大まかな流れは次のとおりです。

1. ブラウザがページに必要な JavaScript バンドル（React や Vue のランタイム、アプリケーションコードなど）をダウンロードして実行します。
2. フレームワークがメモリ上でコンポーネントツリーを再構築します。
3. フレームワークがサーバーでレンダリングされた DOM を走査し、onClick などのイベントリスナーを対応する DOM ノードに取り付けます。
4. フレームワークが、クライアント側のコンポーネント状態とサーバーレンダリング時の状態が一致していることを確認します。

これが完了して初めて、ページは本当の意味で操作可能になります。Hydration は次のように考えられます。完成済みの LEGO 模型（HTML）を受け取ったものの、その一部を動かすには、組み立て説明書（JS）を最初から最後まで読み、すべてのブロックの位置を確認してから、その部品に電池を取り付けなければならない（イベントリスナーを追加する）、というイメージです。

3. Hydration の問題：「操作できないインタラクティブ UI」

Hydration は SSR ページを操作できない問題を解決しますが、それ自体が 「不気味の谷」（Uncanny Valley） または 「Hydration Gap」 と呼ばれる新たなパフォーマンス上のボトルネックをもたらします。

これは、ユーザーがページ内容を目にする時点（FCP）から、ページが実際にユーザー操作へ応答できる時点（TTI）までに時間差があることを指します。その間、ページは使えるように見えますが、実際には「フリーズ」しています。

その原因は次のとおりです。

• JS のダウンロードと実行によるブロック: Hydration を開始する前に、ブラウザは大量の JavaScript コードをダウンロード、解析、実行しなければなりません。
• 高い起動コスト: ページの 90% が操作を必要としない静的コンテンツであっても、フレームワークはクライアント側でコンポーネントツリーの再構築とイベントリスナーの追加に多くの処理を行う必要があります。

4. Hydration の最適化と代替策

Hydration のパフォーマンス問題を解決するため、コミュニティはより高度な複数のパターンを模索してきました。

a. 部分 Hydration（Partial Hydration）

Astro が普及させた Islands Architecture（アイランドアーキテクチャ） は、部分 Hydration の代表的な実装です。核となる考え方は、デフォルトではすべてのコンポーネントが純粋な静的 HTML（JS ゼロ）のみを出力し、操作が必要なコンポーネントだけを明示的に「アイランド」として指定することです。

ビルド時、Astro はこれらの「アイランド」コンポーネントに対してのみ JavaScript をバンドルして送信します。そのため、ブラウザはページ全体ではなく数個の独立した部分だけを Hydrate すればよく、起動時に読み込んで実行する JavaScript の量を大幅に削減できます。

b. 段階的 Hydration（Progressive Hydration）

これは、優先順位に従ってコンポーネントを Hydrate する、より細粒度な最適化戦略です。たとえば、ビューポート内やユーザーがまもなく操作するコンポーネントを優先し、ページ下部にある重要度の低いコンポーネントの処理を遅らせることができます。

c. 再開可能性（Resumability）

Qwik フレームワークは、Hydration を完全になくすことを目指す革新的な概念、Resumability（再開可能性） を提案しています。

その仕組みは次のとおりです。

1. シリアライズ: サーバー側で、Qwik はアプリケーションの全状態、コンポーネント間の関係、イベントリスナーなどの情報をすべてシリアライズし、HTML に埋め込みます。
2. 再開: クライアント側では、Qwik の非常に小さなランタイム（約 1KB）が、起動時にコンポーネントツリーを再構築したり、すべてのイベントを取り付けたりする必要はありません。グローバルイベントリスナーを通じて、ユーザーが特定のボタンをクリックしたときに、どの小さなコード片をダウンロードして実行すべきかを正確に判断できます。

Qwik の目標は Instant-on な操作性です。サーバーの処理をもう一度「実行し直す」のではなく、サーバーが停止した場所から実行を「再開」します。

結論

Hydration はサーバーレンダリングとクライアント操作をつなぐ橋ですが、従来の実装では高コストで、ユーザー体験を損ねる可能性のあるプロセスです。モダンなフロントエンドフレームワークは、部分 Hydration（Astro）や再開可能性（Qwik）といった革新的なパターンによって、この「必要悪」から抜け出し、さらなる高性能と高速な操作性を目指しています。

長い間、Webフロントエンド開発で使われる言語は事実上JavaScriptだけだった。JavaScriptは大きな成功を収めた一方、動的なインタープリター言語であるため、3Dレンダリング、動画のエンコードとデコード、複雑な計算といったCPU負荷の高い処理では、どうしても性能上の限界がある。

WebAssembly（略称WASM）は、この状況を打開するために登場した。JavaScriptを置き換えるものではなく、強力な補完役として、これまでにない性能と可能性をWebプラットフォームにもたらす。

2. WebAssemblyとは何か？

WebAssemblyは、スタックベースの仮想マシン向けに設計されたバイナリ命令形式である。低レベルでアセンブリに似た言語だが、開発者が直接記述することを目的としてはいない。

その代わり、C、C++、Rust、Goなどの高水準言語のコンパイル先として設計されている。こうした高性能な言語でコードを書き、.wasmファイルにコンパイルすれば、ブラウザー内でネイティブに近い速度で実行できる。

重要な点：

• JavaScriptの代替ではない：WASMとJavaScriptは協力関係にある。
• コンパイル先である：C++やRustを書き、WASMへコンパイルする。
• 高速、効率的、移植可能である：設計当初から性能を中心に据えている。

3. JavaScriptとWASMの協調モデル

WASMモジュール自体はサンドボックス環境で動作し、DOMへ直接アクセスしたり、Web APIを呼び出したり、ネットワークリクエストを送ったりできない。これらの操作はすべて、JavaScriptが仲介する「接着剤」の層を通じて行う必要がある。

典型的な協調モデルは次のとおりだ：

1. JavaScriptが全体を取りまとめる：JSコードはアプリケーション全体のロジックを担い、ユーザーイベントを処理し、DOMを更新する。
2. WASMが計算を担う：計算負荷の高い処理が必要になると、JSは.wasmモジュールからエクスポートされた関数を呼び出す。
3. データをやり取りする：JSとWASMは、主に数値型や線形メモリのブロックを効率よく交換できる。

JavaScriptを「マネージャー」、WebAssemblyを「熟練エンジニア」と考えると分かりやすい。マネージャーは連絡と調整を担当し、エンジニアは最も難しい技術課題を解決する。

4. 実際の利用例

WASMはもはや実験的な技術ではない。多くの一流Webアプリケーションが中核機能に採用している：

• Figma：この人気オンラインデザインツールの中核レンダリングエンジンはC++で書かれ、WASMへコンパイルされている。そのため、滑らかなグラフィック編集を実現できる。
• Adobe Photoshop & Lightroom：Adobeは主力デスクトップアプリケーションのC++コアコードをWASMでWebへ移植し、ブラウザー上で高機能なPhotoshopを利用できるようにした。
• Google Earth：新しいGoogle Earthはすべてブラウザー内で動作し、複雑な3D地球レンダリングをWASMが支えている。
• AutoCAD Web App：Autodeskは大規模なC++製CADエンジンをWASMへコンパイルし、完全なAutoCADをブラウザー内で動かせるようにした。

これらの事例は、従来はデスクトップアプリケーションにしか実現できないと考えられていた複雑なソフトウェアを、WASMがすでにWebプラットフォームへ持ち込めることを示している。

5. 未来：WASIとブラウザーの外側

WASMの狙いはブラウザーだけにとどまらない。WASI（WebAssembly System Interface） は、ファイルシステムやネットワークへのアクセスなど、標準的なシステムレベルAPIをWASMに提供するための新しい標準である。

つまり将来、.wasmファイルは汎用的でクロスプラットフォームかつ安全なバイナリ形式となり、サーバー（Dockerへの挑戦）、エッジコンピューティングのノード、IoTデバイスまで、あらゆる場所で動作するかもしれない。まさに「一度コンパイルすれば、どこでも動く」が実現する。

結論

WebAssemblyは、Webアプリケーションの能力の限界に対する私たちの認識を大きく変えている。JavaScriptは得意分野であるUI操作とアプリケーションロジックの取りまとめに集中し、性能の「天井」はRustやC++といったシステム言語からコンパイルされたWASMモジュールへ任せられる。フロントエンド開発者にとって、WASMの能力と適切な利用場面を理解することは、次世代の高性能Webアプリケーションを構築するうえで重要になる。

Web 開発では、長い間ユーザー体験に関する次のようなジレンマがありました。

• マルチページアプリケーション（MPA）: アーキテクチャは単純で安定していますが、ページを移動するたびに完全な読み込みが発生し、「白い画面」や「ちらつき」によって体験の連続性が失われます。
• シングルページアプリケーション（SPA）: フロントエンドルーティングによってリロードのない滑らかな体験を実現しますが、開発者は複雑な遷移アニメーション、状態管理、コード分割を手動で扱う必要があり、開発コストが高くなります。

MPA の単純さを保ちながら、SPA の滑らかな遷移も得られる方法はないのでしょうか。View Transitions API は、まさにそのために生まれました。

2. View Transitions API とは？

View Transitions API はブラウザネイティブの API で、異なる二つの DOM 状態の間にアニメーション遷移を簡単に作成する仕組みを提供します。

基本的な処理の流れは非常に単純です。

1. 遷移を開始すると、API が現在のページ（古い状態）の「スナップショット」を撮ります。
2. 次に JavaScript で DOM を新しい状態へ更新します。
3. API が新しいページ（新しい状態）の「スナップショット」も撮ります。
4. 最後にブラウザが「古いスナップショット」と「新しいスナップショット」の間に、通常はフェードイン・フェードアウトによる滑らかなデフォルト遷移を作ります。

これらはすべてブラウザの内部で効率よく処理されるため、必要なのは単純な関数を一つ呼び出すことだけです。

3. 使い方

シングルページアプリケーションで View Transitions を使うのは非常に簡単です。DOM の更新処理を document.startViewTransition 関数で包むだけです。

// 假设你有一个更新页面内容的函数
async function updatePageContent(url) {
  const response = await fetch(url);
  const newHtml = await response.text();
  // 用新内容替换旧内容 (具体实现取决于你的架构)
  document.body.innerHTML = newHtml;
}

// 在导航链接的点击事件中调用
document.querySelector('a').addEventListener('click', (event) => {
  event.preventDefault();
  const url = event.target.href;

  // 检查浏览器是否支持
  if (!document.startViewTransition) {
    updatePageContent(url); // 不支持则直接更新
    return;
  }

  // 使用 View Transition
  document.startViewTransition(() => updatePageContent(url));
});

これだけで、ページ遷移にデフォルトのフェード効果が加わります。

4. 遷移アニメーションのカスタマイズ

デフォルトのフェード効果も優れていますが、この API の真価はカスタマイズ性にあります。startViewTransition の実行時、ブラウザは次の疑似要素を含む DOM 構造を作成します。

• ::view-transition: 遷移全体を含むルート要素。
• ::view-transition-old(root): 古いビューの「スナップショット」。
• ::view-transition-new(root): 新しいビューの「スナップショット」。

CSS の animation でデフォルト効果を上書きできます。たとえば、次のようなスライドインアニメーションを実装できます。

@keyframes slide-in {
  from { transform: translateX(100%); }
}

::view-transition-new(root) {
  animation: slide-in 0.5s ease-out;
}

5. 要素間の「変形」：view-transition-name

この API で最も驚くべき機能は、二つのページにある 異なる要素 を 同じオブジェクト として認識し、その間に滑らかな「変形」アニメーションを作れることです。

これは CSS プロパティ view-transition-name によって実現されます。

ページ A（一覧ページ）:

<img src="thumbnail.jpg" style="view-transition-name: hero-image;" />

ページ B（詳細ページ）:

<img src="full-size.jpg" style="view-transition-name: hero-image;" />

ページ A からページ B に移動すると、ブラウザは二つの要素の view-transition-name が同じであることを認識します。そして位置、サイズ、形状の差を自動的に計算し、単純なフェードではなく滑らかな遷移アニメーションを生成します。画像やカードなどの要素の遷移に特に適しています。

結論

View Transitions API は、待望されていたネイティブの遷移機能を Web にもたらします。従来は複雑な JavaScript アニメーションライブラリが必要だったインタラクションを大幅に単純化し、映画のように滑らかなアプリケーション体験をかつてないほど簡単に作れるようにします。Astro や Nuxt などのフレームワークへの統合が進み、将来マルチページアプリケーションにも普及すれば、モダン Web 開発者の標準スキルの一つになるでしょう。

React Server Components（RSC）は、ビルド時またはサーバー上でレンダリングされる新しい種類の React コンポーネントです。クライアントのブラウザでレンダリングされる従来のコンポーネント（現在は「Client Components」と呼ばれます）とは異なり、RSC のコードがクライアントへ送信されることはありません。ブラウザが受け取るのは、レンダリング済みの HTML または特殊なストリーミング形式だけです。

これは、React が純粋なクライアントサイドライブラリから、サーバーとクライアントの間でシームレスに動作するフルスタックフレームワークへと進化したことを示します。

2. RSC はどのような問題を解決するのか？

RSC は主に、次のような中心的な課題を解決するために登場しました。

• 巨大な JavaScript バンドルサイズ: 従来の React アプリケーションは、直接操作しないコンポーネントも含め、すべてのコンポーネントの JS コードをバンドルしてクライアントへ送るため、初期読み込みが遅くなります。RSC を使えば、テキスト、レイアウト、データ表示など多くのコンポーネントをサーバー側に残し、JS サイズをゼロにできます。
• リクエストウォーターフォール（Request Waterfalls）: クライアントでデータを取得する典型的な流れは、コンポーネントをレンダリング -> useEffect -> リクエストを送信 -> データを待機 -> 再レンダリング、というものです。コンポーネントのネストが深いとリクエストウォーターフォールが発生し、ページの表示が遅くなります。RSC はサーバーで直接 async/await によるデータ取得を行い、データとコンポーネントを一緒にクライアントへストリーミングできるため、この問題を根本から解決します。
• バックエンド資源への直接アクセス: RSC は Node.js などのサーバー環境で実行されます。そのため、クライアント向けに追加の API エンドポイントを公開することなく、データベース、ファイルシステム、内部 API へ直接かつ安全にアクセスできます。

3. Server Components と Client Components

両者の違いを理解することが、RSC を使いこなす鍵です。

経験則: デフォルトではすべてのコンポーネントを Server Components と考えます。コンポーネントで useState や useEffect を使う、または onClick などのユーザーイベントを処理する必要がある場合にだけ、ファイルの先頭へ "use client"; ディレクティブを追加して Client Component として指定します。

4. 両者はどのように連携するのか？

現代の React アプリケーションは、両者を組み合わせたものになります。たとえば、ブログ記事のページでは次のように構成できます。

• PageLayout（Server Component）: 全体のレイアウトを担当します。
• ArticleContent（Server Component）: データベースまたは Markdown ファイルから記事データを取得してレンダリングします。
• LikeButton（Client Component）: useState と onClick イベントを持ち、「いいね」の操作を処理します。
• Comments（Client Component）: コメントを取得して表示し、フォーム送信などの操作を扱います。

Server Components はサーバー側で Client Components のための「場所」を確保し、最終的にブラウザ上で両者をシームレスに組み合わせられます。

まとめ

React Server Components は大きなパラダイムシフトです。React の能力をブラウザからサーバーへ拡張し、明確なパフォーマンス上の利点と、より優れた開発体験をもたらします。新しいメンタルモデルは必要になりますが、Next.js App Router などのフレームワークで実践されることで、RSC は高性能でスケーラブルな Web アプリケーションを構築する新たな標準になりつつあります。

Node.jsアプリケーションでは、process.envを通じて環境変数へアクセスする。簡単で有効な仕組みだが、型安全ではないという本質的な問題がある。

process.envオブジェクトの値は、stringかundefinedのどちらかである。そのため、よくある問題がいくつか生じる：

• 予期しないundefined：.envファイルやサーバーに変数を設定し忘れると、実行時のprocess.env.MY_VARはundefinedになる。これがコードの深い部分でTypeErrorを引き起こすことがある。
• 型の不一致：ポート番号をnumber型として扱いたくても、process.env.PORTは常に文字列である。使用する場所ごとに手動でparseIntを呼ぶ必要がある。
• 検証ロジックの分散：const port = process.env.PORT || 3000;のような防御的コードを各所に書きがちで、環境変数の管理が散らかってしまう。

2. 中心原則：起動時に失敗する（Fail-Fast）

環境変数のような重要な設定では、ベストプラクティスは 「起動時に失敗する」（Fail-Fast） ことである。

つまりアプリケーションは、起動直後に必要な環境変数がすべて用意され、形式も正しいかを確認するべきだ。問題があれば、設定ミスによって将来の予測できない時点でクラッシュするのではなく、すぐにエラーを投げて停止する。

これにより、ユーザーがアクセスしたときではなく、デプロイや開発の時点で設定の問題を直ちに発見できる。

3. Zodで型安全な検証を実現する

ZodはTypeScriptを第一に設計されたスキーマ宣言・検証ライブラリである。環境変数の型安全性という問題を解決するのに適している。

戦略は次のとおりだ：

1. すべての環境変数に対するZodスキーマを定義する。
2. アプリケーションの起動時に、そのスキーマでprocess.envを解析する。
3. 解析に失敗した、つまり検証を通らなかった場合は、Zodがエラーを投げ、アプリケーションの起動も失敗する。
4. 解析に成功すれば、完全に型付けされたオブジェクトを取得し、アプリケーション全体で利用する。

実装例

まずZodをインストールする：pnpm add zod

次に、src/env.tsなど、環境変数を扱う専用ファイルを作成する：

// src/env.ts
import { z } from 'zod';

// 1. 定义 Schema
const envSchema = z.object({
  NODE_ENV: z.enum(['development', 'production', 'test']).default('development'),
  DATABASE_URL: z.string().min(1, 'DATABASE_URL is required.'),
  PORT: z.coerce.number().int().positive().default(3000),
  // z.coerce 会尝试将字符串转换为数字
});

// 2. 解析和导出
// .parse 会在验证失败时抛出错误，实现 "Fail-Fast"
export const env = envSchema.parse(process.env);

これでアプリケーション内のどこからでも、src/envからenvオブジェクトをインポートできる。

// src/server.ts
import { env } from './env'; // 导入经过验证和类型化的 env 对象

// env.PORT 的类型是 `number`，而不是 `string | undefined`
const port = env.PORT;

// env.NODE_ENV 的类型是 'development' | 'production' | 'test'
if (env.NODE_ENV === 'development') {
  console.log('Running in development mode');
}

// 如果 DATABASE_URL 未设置，应用在启动时就已经崩溃了，
// 所以在这里我们可以放心地认为它是存在的，并且类型是 `string`。
connectToDatabase(env.DATABASE_URL);

4. 得られる利点

このパターンには、すぐに実感できる利点がある：

• 完全な型安全性：コードでenv.PORTへアクセスするとき、TypeScriptはそれがnumberだと把握している。
• ドキュメントと検証の集約：env.tsファイル自体が環境変数の信頼できるドキュメントとなり、すべての検証ロジックも一か所にまとまる。
• 信頼できる実行環境：環境変数のタイプミス、欠落、形式の誤りによる実行時バグを防ぐ。
• Fail-Fast：設定上の問題をデプロイや開発の最初の段階で発見できる。

結論

環境変数の検証をアプリケーションの起動時へ前倒しし、Zodのようなツールで型安全性を保証することは、費用対効果の非常に高いエンジニアリング手法である。アプリケーションの堅牢性と開発者の自信を大きく高められるため、現代のTypeScriptプロジェクトに欠かせない要素だ。

2024年初め、Vueチームはコードネーム「Slam Dunk」と呼ばれるバージョン3.4をリリースした。3.0ほど抜本的なバージョンではないものの、内部の性能最適化と開発者体験の向上という二つの重要な領域で大きな改善をもたらした。

なかでも注目すべき変更は、リアクティブシステムの書き直し、安定版となったdefineModel API、そしてより簡潔なv-bind構文である。

2. リアクティブシステムの再構築

Vue 3.4では、中核となるリアクティブシステムが大幅に書き直された。主な目的は、computedによる算出プロパティの効率を高めることにある。

従来のバージョンでは、依存先が実際には変化していなくても、算出プロパティが不要に再計算されることがあった。新しいバージョンでは、より賢い依存関係の追跡によって、本当に必要なときだけ計算を実行し、不要なコンポーネントの再レンダリングを減らしている。

多くの開発者にとって、これは「無料の昼食」だ。コードを一切変更しなくても、3.4へアップグレードするだけで性能向上を自動的に得られる。

3. defineModel：コンポーネントの双方向バインディングを美しく

3.4より前は、コンポーネントにv-modelのような双方向バインディングを実装するために、かなりの定型コードが必要だった：

以前 👎：

<script setup>
const props = defineProps(['modelValue'])
const emit = defineEmits(['update:modelValue'])

// 通常需要一个计算属性来包装
const value = computed({
  get: () => props.modelValue,
  set: (val) => emit('update:modelValue', val)
})
</script>

<template>
  <input v-model="value" />
</template>

Vue 3.4では、defineModel APIが実験段階を終えて正式な安定版になった。今では、同じ機能を一行のコードで実現できる：

現在（Vue 3.4）👍：

<script setup>
const model = defineModel()
</script>

<template>
  <input v-model="model" />
</template>

defineModelマクロはmodelValue propとupdate:modelValueイベントを自動的に登録し、直接読み書きできるrefを返す。これにより、v-modelに対応するコンポーネントの開発が大幅に簡単になる。

4. 同名属性に対するv-bindの省略記法

開発体験を高めるもう一つのシンタックスシュガーが、同名の場合に使えるv-bindの省略記法だ。コンポーネントへ渡すpropと<script setup>で定義した変数が同じ名前なら、属性値を省略できるようになった。

以前 👎：

<script setup>
const id = 'my-id'
const title = 'Hello Vue'
</script>

<template>
  <MyComponent :id="id" :title="title" />
</template>

現在（Vue 3.4）👍：

<script setup>
const id = 'my-id'
const title = 'Hello Vue'
</script>

<template>
  <MyComponent :id :title />
</template>

この小さな変更によって、テンプレートのコードがよりすっきりと読みやすくなる。

結論

Vue 3.4は堅実なアップデートである。低レベルの性能最適化と高レベルAPIの簡素化により、「プログレッシブ」なフレームワークというVueの理念をさらに強固にした。大規模アプリケーションには強力な性能を保証し、日々の開発には具体的な利便性をもたらす。特にdefineModelの安定化は、コンポーネントのカプセル化に長く存在した課題を解決したもので、今回の更新で最も評価すべき点である。

モダンなフロントエンド開発では、プロジェクトを円滑に動かすために、通常は複雑なツールの組み合わせが必要です。

• Linter：ESLintはJavaScript/TypeScriptコードの品質を検査します。
• Formatter：Prettierはコードスタイルを統一します。
• Compiler：BabelまたはTypeScript（tsc）はコードを変換します。
• Bundler：Webpack、Rollup、Viteはコードをバンドルします。

これらのツールの設定、プラグイン、バージョン、相互作用を管理すること自体が大きな仕事です。これがいわゆる「ツール疲れ」です。コミュニティは長年にわたり、1つのツールですべての問題を解決する「オールインワンツールチェーン」の可能性を模索してきました。

2. Romeの構想とBiomeの誕生

Romeは、Facebookの元従業員でBabelの作者でもあるSebastian McKenzieが始めた野心的なプロジェクトで、フロントエンドツールチェーン全体をTypeScriptで書き直すことを目指していました。その構想は、設定不要で高性能な統合ツールを提供することでした。しかし、長年の開発と商業化の試みを経た後、Rome Labsは2023年に事業停止を発表しました。

幸い、Romeのコアコードはオープンソースでした。コミュニティはすぐに動き、Biomeという名前のフォークを作成し、専用のコミュニティ組織が保守することで、Romeの当初の構想を継承し実現しようとしています。

3. Biomeとは？

BiomeはRustで書き直された高性能なフロントエンドツールチェーンです。ESLintやPrettierなど一連の独立したツールに代わる、統合された非常に高速な開発体験を提供することを目指しています。

2023年末の時点で、Biomeの中核機能は主にLinterとFormatterに集中しており、どちらでも驚くべき実力を示していました。

主な利点：

• 圧倒的な性能：Rustのおかげで、BiomeはJavaScriptで書かれたESLintやPrettierよりはるかに高速に動作します。大規模なコードベースでは、性能向上が1桁違うこともあります。
• 統一された設定：1つのbiome.jsonファイルだけで、すべてのツールの動作を管理でき、各所に散らばった.eslintrc、.prettierrc、.editorconfigから解放されます。
• 詳細な診断情報：BiomeのLinterはエラーを指摘するだけでなく、非常に詳しいコンテキストと修正提案を提供し、開発者が問題の根本原因を理解できるようにします。
• Prettierとの互換性：BiomeのフォーマッターはPrettierのルールの95%以上との互換性を目指しており、Prettierからの移行コストを非常に低く抑えます。

4. クイックスタート

npxを使って、プロジェクト内ですぐにBiomeを試せます。

# 检查当前项目中的代码问题
npx @biomejs/biome check ./src

# 自动修复可修复的 lint 问题
npx @biomejs/biome check --apply ./src

# 格式化代码
npx @biomejs/biome format --write ./src

biome.jsonファイルを作成すると、ルールと設定をカスタマイズできます。

{
  "$schema": "https://biomejs.dev/schemas/1.4.1/schema.json",
  "organizeImports": {
    "enabled": true
  },
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true
    }
  }
}

5. 今後の展望

Biomeのロードマップは非常に明確です。LinterとFormatterを安定させた上で、Compiler、Bundler、Test Runnerなどの機能を段階的に実装し、最終的に名実ともに「オールインワン」のツールチェーンになることを目指しています。

Biomeはまだ若いものの、優れた性能、コミュニティ主導のオープンなモデル、開発者体験への注力によって、フロントエンドツール分野で無視できない新勢力となっています。ツールスタックを簡素化し、開発効率を高めたいチームにとって、Biomeは非常に魅力的な将来の選択肢です。

10年以上にわたり、Node.jsはサーバーサイドJavaScriptの代名詞でした。DenoがセキュリティやモダンなAPIについて新しい考え方を示したものの、Node.jsの地位が本当に揺らいだようには見えませんでした。しかし2023年9月、Bun 1.0が正式にリリースされたことで、状況は変わるかもしれません。

Bunは単なる別のJavaScriptランタイムではありません。ゼロから設計された、パフォーマンス重視の「オールインワン」ツールキットであり、開発からデプロイまでのライフサイクル全体を担うことを目指しています。

2. Bunの核心：速度、速度、そして速度

Bunの第一の設計目標はパフォーマンスです。そのために、いくつかの独自な技術選択を行っています。

• Zig言語：Bunの基盤はZigで書かれています。Zigはパフォーマンスとメモリ制御を重視するモダンなシステムプログラミング言語であり、低レベルの細部まで徹底的に最適化できます。
• JavaScriptCoreエンジン：GoogleのV8エンジンを使うNode.jsやDenoとは異なり、BunはAppleのJavaScriptCore（JSC）エンジンを選びました。JSCは起動が速く、一般にメモリ消費も少ないことで知られています。

こうした選択により、Bunはスクリプトの起動、bun installの速度、組み込みAPIの実行効率で驚異的なパフォーマンスを示しています。

3. ランタイムだけではない

Bunの「オールインワン」設計も大きな特徴です。単なるnodeコマンドの代替ではなく、次の機能も内蔵しています。

• パッケージマネージャー：bun installはnpm installの数倍、場合によっては数十倍高速です。グローバルモジュールキャッシュと効率的な依存関係解決アルゴリズムを使い、インストール時間を大幅に短縮します。
• ビルドツール／バンドラー：Bunは高性能なバンドラーを内蔵し、プロジェクトを実行ファイルやブラウザー向けコードへ直接まとめられます。その性能はesbuildに匹敵します。
• ネイティブトランスパイラー：TypeScript（.ts）やJSX（.jsx、.tsx）ファイルを、tscやbabelを事前に設定せず直接実行できます。Bunは実行時にそれらを非常に高速で変換します。
• テストランナー：bun testはJestとの高い互換性を持つテスト環境を提供しながら、はるかに高速に動作します。

つまり新しいプロジェクトでは、bunという1つのツールをインストールするだけで、開発、テスト、バンドルの全工程をこなせる可能性があります。

4. Node.jsとの互換性

移行を容易にするため、BunチームはNode.js APIとの互換性の実現に多大な労力を注いでいます。node_modulesの解決、CommonJS（require）とESM（import）モジュール、さらにfs、path、httpなど多数のNode.jsコアモジュールをサポートしています。

既存のNode.jsプロジェクトの多くは、理論上bunでそのまま実行し、すぐにパフォーマンス向上の恩恵を受けられます。

5. 課題と未来

Bunの登場は、フロントエンド界で長く続いてきた「小さな専用ツールを組み合わせる」という思想に挑戦しています。「大きく全部入り」のモデルは、比類のない利便性とすぐに使える高性能をもたらす一方で、柔軟性の一部を犠牲にする可能性もあります。

Node.jsには非常に巨大で成熟したエコシステムがあり、Bunが短期間で追いつくのは困難です。しかしBun 1.0のリリースは、本番環境に対応する準備が整ったことを示しました。その驚異的な性能と統合された開発体験は、新規プロジェクトや究極の効率を求めるチームにとって抗いがたい魅力を持っています。

Bunが将来Node.jsの地位を覆せるかどうかにかかわらず、その登場はすでにJavaScriptツールチェーンの発展に新たな活力を注ぎ、新しいパフォーマンス基準を打ち立てています。

数年前にフロントエンドコードを書いたことがあれば、SassやLessをよく知っているはずです。これらのCSSプリプロセッサーには、ほぼすべての開発者に愛される機能があります。セレクターのネスト（Nesting） です。HTMLを書くように子セレクターのルールを親セレクターの内側へ記述でき、コードの可読性と構成を大きく改善します。

// Sass 语法
nav {
  ul {
    margin: 0;
    padding: 0;
    list-style: none;
  }

  li { display: inline-block; }

  a {
    display: block;
    padding: 6px 12px;
    text-decoration: none;
  }
}

長年、この構文をブラウザーが理解できる通常のCSSへコンパイルするため、ビルドツールに頼ってきました。しかし今、状況は変わりました。

2. ネイティブCSS Nestingの登場

2023年初頭から、主要ブラウザーのChrome、Safari、Firefoxが相次いでネイティブのCSS Nesting Moduleへの対応を発表しました。つまり、前処理を一切せずに.cssファイルへ直接ネストしたルールを書けます。

上の例はネイティブCSSで次のように書けます。

/* 原生 CSS 语法 */
nav {
  ul {
    margin: 0;
    padding: 0;
    list-style: none;
  }

  li { display: inline-block; }

  a {
    display: block;
    padding: 6px 12px;
    text-decoration: none;
  }
}

そうです。Sassとまったく同じように見えます。

3. &の重要な役割

プリプロセッサーと同じく、&記号はネイティブのネストでも重要な役割を果たし、親セレクターを表します。疑似クラス、疑似要素、組み合わせセレクターを扱うときに特に便利です。

.card {
  background: white;
  border-radius: 8px;

  /* & 代表 .card */
  &:hover {
    box-shadow: 0 4px 12px rgba(0,0,0,0.1);
  }

  /* & 代表 .card，组合成 .card.dark-mode */
  &.dark-mode {
    background: #333;
  }

  /* & 代表 .card，组合成 .card > .header */
  > .header {
    font-weight: bold;
  }
}

4. Sassとの小さいが重要な違い

Sassでは、.card { .title { ... } }のようにクラスセレクターを直接ネストできます。ネイティブCSS Nestingの初期仕様ではこれは認められず、ネストしたルールはすべて&、>、+、~などの記号で始める必要がありました。

最新仕様ではこの制限が緩和され、article { h1 { ... } }のように型セレクターを直接ネストできるようになりました。それでもクラスセレクターをネストするときは、意図を明確にして曖昧さを避けるため、&を使うのがベストプラクティスです。

/* 推荐写法 */
.article {
  & .author-name {
    font-style: italic;
  }
}

/* 不推荐的写法 (在某些早期实现或严格解析器中可能无效) */
.article {
  .author-name {
    font-style: italic;
  }
}

&を使うと、.author-nameが.articleの子孫であることを明確に表せます。

5. ブラウザー対応と今後

2023年9月時点で、主要なモダンブラウザー（Chrome 112+、Safari 16.5+、Firefox 117+）はすべてCSS Nestingに対応しています。つまり、本番環境でも段階的に使い始められます。

ネイティブCSS Nestingの登場は、Webプラットフォーム自体の進化における新たな重要な節目です。ビルドツールへの依存を減らし、CSS自体をより強力で表現豊かにすると同時に、フロントエンドを学び始めた開発者も、より直感的にスタイルコードを書いて理解できるようになります。

Utility-First が登場する以前から、スタイルを整理するための優れた CSS 方法論は数多く存在していました。たとえば次のようなものです。

• BEM (Block, Element, Modifier): block__element--modifier という命名規則によって、スタイルの独立性と保守性を確保します。
• OOCSS (Object-Oriented CSS): 構造と見た目を分離し、コンテナとコンテンツも分離することを提唱します。
• CSS-in-JS: CSS を JavaScript コンポーネント内に直接記述し、コンポーネント単位でスタイルをカプセル化します。

これらの方法は CSS のグローバル汚染やコード整理の問題をある程度解決しましたが、多くの場合、新たな問題も生みました。無数の class を命名するための思考負荷、ファイルを切り替える煩わしさ、そして CSS-in-JS がもたらす可能性のある実行時コストです。

2. Utility-First とは？

Utility-First（ユーティリティ優先）とは、単一の目的を持ち、名前が変わらないユーティリティクラスを一式用意し、それらを組み合わせて複雑な UI を構築するという CSS の考え方です。

たとえば .card クラスを作り、CSS ファイル内で display、padding、box-shadow を定義するのではなく、 HTML に直接次のように記述します。

<div class="block p-6 rounded-lg shadow-lg bg-white">
  
</div>

ここで使われている block、p-6、rounded-lg などはユーティリティクラスで、それぞれが一つの小さな役割だけを担います。

3. Tailwind CSS：Utility-First の代表例

Tailwind CSS は現在最も人気のある Utility-First CSS フレームワークです。一般的な CSS プロパティをほぼすべて網羅する、非常に詳細なユーティリティクラス群を提供します。

主な利点:

• 非常に高速な開発: HTML ファイルからほとんど離れる必要がありません。アトミッククラスを組み合わせることで、あらゆるデザインを素早く構築でき、プロトタイピングと開発の効率が大幅に向上します。
• デザインシステムの強制: すべてのスタイル（色、余白、文字サイズ）が事前定義された設定（theme）に由来するため、チーム全体で UI の一貫性を保ちやすく、「マジックナンバー」も避けられます。
• 命名の悩みが不要: 「コンピュータサイエンスの二大難問は、キャッシュの無効化と命名である。」Tailwind を使えば、CSS クラスの命名にほとんど悩まなくて済みます。
• 優れたパフォーマンス: 本番ビルド時に Tailwind はファイルを走査し、PurgeCSS（または内蔵 JIT エンジン）によって未使用の CSS クラスをすべて削除するため、最終的な CSS ファイルは通常非常に小さくなります。

4. 「クラス名地獄」？—— 欠点を見る別の視点

Tailwind に対する最も一般的な批判は、HTML が非常に肥大化して読みにくくなり、「インラインスタイル」の時代に戻ったように見えることです。

<button class="py-2 px-4 font-semibold rounded-lg shadow-md text-white bg-blue-500 hover:bg-blue-700">
  Click me
</button>

確かに慣れが必要です。しかし支持者は次のように考えます。

1. スタイルと構造はもともと密接に結び付いているため、同じ場所に置く方がむしろ保守しやすい。
2. React や Vue のコンポーネントなど、再利用可能なコンポーネントとして切り出せば、この「混乱」を内部に閉じ込められる。

再利用したいスタイルの組み合わせに対して、Tailwind は @apply ディレクティブを提供しています。

/* in your css file */
.btn-primary {
  @apply py-2 px-4 font-semibold rounded-lg shadow-md text-white bg-blue-500 hover:bg-blue-700;
}

これで HTML 内から .btn-primary を使用できます。ただし Tailwind 公式は、再利用の問題をコンポーネント化によって解決することをより推奨しています。

結論

Utility-First と Tailwind CSS の成功は、フロントエンド開発における「関心の分離」の考え方が、言語の分離（HTML/CSS/JS）からコンポーネントの分離へ移ったことを示しています。一見「原始的」に見える方法で、モダン Web 開発の多くの実際的な問題を解決し、効率的で一貫性があり、高性能な UI への近道を開発者に提供します。

エンドツーエンド（E2E）テストは、アプリケーションの品質を守る最後の防衛線である。クリック、入力、移動といった実際のユーザー操作を再現し、アプリケーション全体の流れが円滑に動くかを検証する。しかしE2Eテストは、「壊れやすい」「不安定」としても知られている：

• 非同期の問題：スクリプトの実行時にDOM要素の読み込みが終わっておらず、テストが失敗することがある。開発者は大量のwaitやsleepを手動で追加する必要があり、テストの信頼性が下がる。
• クロスブラウザー互換性：主要ブラウザー（Chrome、Firefox、Safari）のすべてでテストを安定して動かすことは大きな課題である。
• デバッグの難しさ：CI/CD環境でテストが失敗したとき、現場のスナップショットやネットワークログがないため、問題の再現と特定が非常に難しい。

こうした問題を解決するために次世代のテストツールが登場し、Playwrightはその代表格となっている。

2. Playwrightとは何か？

PlaywrightはMicrosoftが開発したNode.jsライブラリで、Chromium（Chrome、Edge）、Firefox、WebKit（Safari）を自動操作する。Google Puppeteerを最初に開発したチームの中心メンバーが作ったもので、Puppeteerの精神的な後継者と見なせるが、設計はより現代的で強力である。

3. Playwrightの主な強み

a. 真のクロスブラウザーテスト

これはPlaywrightの最も際立った長所である。統一された一つのAPIを使い、主要な三つのブラウザーエンジンすべてで動くテストを書ける。Safariのような特定のブラウザーでしか発生しないバグも簡単に発見し、修正できる。

b. 自動待機（Auto-Waits）

Playwrightは非同期の問題を根本から解決する。page.click()などの操作を実行する前に、次のような一連の操作可能性チェックを自動で行う：

• 要素がDOMに現れるまで待つ。
• 要素が表示されるまで待つ。
• アニメーションが要素を覆わなくなるまで待つ。
• 要素がイベントを受け取れるまで待つ。

そのため、手動の待機コードをほとんど書く必要がなくなり、テストの安定性が大幅に高まる。

c. 強力な付属ツール

• Codegen（コードジェネレーター）：画期的な機能である。pnpm exec playwright codegen example.comを実行すると、Playwrightがブラウザーウィンドウを開く。そこで行ったすべての操作が自動的に記録され、テストコードへ変換される。E2Eテストを書くためのハードルを大きく下げてくれる。

• Trace Viewer（トレースビューアー）：Playwrightの「タイムマシン」である。テストに失敗したとき、完全なテストトレースファイルを生成できる。Trace Viewerで開けば、次のことが可能だ：

  • テストの各ステップにおけるDOMスナップショットを確認する。
  • 完全なネットワークリクエストログを確認する。
  • consoleログとエラー情報を確認する。
  • タイムラインを前後に動かし、各操作の前後でページがどう変化したかを直感的に確認する。

これにより、CIで失敗したケースのデバッグがかつてないほど簡単になる。

4. 簡単なテスト例

PlaywrightのAPIは非常に直感的に設計されている。

import { test, expect } from '@playwright/test';

test('页面应有正确的标题', async ({ page }) => {
  await page.goto('https://playwright.dev/');

  // 断言页面的 title 包含 "Playwright"
  await expect(page).toHaveTitle(/Playwright/);
});

test('点击 "Get started" 链接应跳转到介绍页', async ({ page }) => {
  await page.goto('https://playwright.dev/');

  // 通过角色和名称定位并点击链接
  await page.getByRole('link', { name: 'Get started' }).click();

  // 断言 URL 包含 "intro"
  await expect(page).toHaveURL(/.*intro/);
});

結論

Playwrightは、優れたクロスブラウザー対応、信頼できる自動待機、比類のないデバッグツール（特にTrace Viewer）により、現代のWebアプリケーションにおけるE2Eテストの新たな基準を打ち立てた。テストの安定性と信頼性を高めるだけでなく、Codegenなどのツールによってテスト作成の体験も大きく改善する。プロジェクトに現代的で強力なテスト自動化手段を求めているなら、Playwrightは間違いなく有力な選択肢の一つだ。

フロントエンド開発の本質は「状態を UI に対応づけること」です。長年にわたり、リアクティブモデルは絶えず進化してきました。手動の DOM 操作から MVC/MVVM パターンへ、そして React が普及させた仮想 DOM（Virtual DOM）へと移り変わってきたのです。VDOM はコンポーネント単位で状態変更をまとめて処理し、Diffing を行うことで、UI 開発を大幅に簡素化しました。

しかし、VDOM は万能薬ではありません。コンポーネント単位の再レンダリングと Diffing のコストは、動的な処理が特に多い場面ではパフォーマンスのボトルネックになり得ます。近年、より古いパラダイムを現代のコンパイラで最適化した「きめ細かなリアクティビティ（Fine-Grained Reactivity）」が再び表舞台に戻り、その中核を担っているのが Signals です。

2. Signals とは？

Signal は、値を包み込み、その値が変化したときにすべての依存先へ自動的に通知できるリアクティブプリミティブ（Reactive Primitive）です。コンポーネント単位で変化を追跡する VDOM フレームワークとは異なり、Signal はデータが読み取られる段階で依存関係グラフを自動的に構築します。

Signal の値が更新されると、その Signal に直接または間接的に依存する計算（Memo）や副作用（Effect）だけが再実行されます。これにより「外科手術」のように正確な DOM 更新が可能になり、VDOM の Diffing はまったく必要ありません。

その中核は通常、次の 3 つのプリミティブで構成されます。

• createSignal(value): リアクティブな state の単位を作成します。
• createEffect(() => {}): 依存関係を自動追跡し、変更に反応する副作用を作成します。
• createMemo(() => {}): 派生した、キャッシュ付きのリアクティブな計算を作成します。

// SolidJS 语法示例
const [count, setCount] = createSignal(0);

const doubleCount = createMemo(() => count() * 2);

createEffect(() => {
  console.log(`The double count is: ${doubleCount()}`);
});

setCount(1); // 这将触发 memo 重新计算，并触发 effect 重新执行

重要なメンタルモデルは、SolidJS のような Signal ベースのフレームワークでは、コンポーネント関数そのものは初期化時に一度だけ実行されるという点です。その後の更新はコンポーネントの再レンダリングではなく、リアクティブシステムによって完全に駆動されます。

3. エコシステム全体での幅広い採用

Signal はまったく新しい概念ではなく、その考え方は Knockout.js など初期のフレームワークにまで遡れます。しかし、現代の JavaScript コンパイラによって新たな活力を得て、主要なフレームワークに幅広く採用されています。

• SolidJS & Qwik: Signal を全面的な基盤として構築されており、このパラダイムの模範的な実装です。
• Preact: @preact/signals パッケージによって公式サポートを導入し、既存の Preact/React プロジェクトにも統合できます。
• Vue: Composition API の ref と computed は、本質的には Signal の一種の実装です。
• Svelte 5: まもなく登場する「Runes」アップデートは、Svelte チームによるリアクティブモデルの再構築であり、その中核では Signal パラダイムを参考にして実装しています。
• Angular: 最近のバージョンでは、新しいリアクティブプリミティブとして Signals が導入されています。

このようにフレームワークをまたいで同じ方向へ収束していることは、効率的で予測可能なリアクティブモデルとしての Signal の価値を証明しています。

4. 利点とトレードオフ

利点：

1. 優れたパフォーマンス: VDOM とコンポーネント単位の再レンダリングを回避するため、ベンチマークでは通常、優秀な結果を示します。
2. 予測可能性: 状態更新の流れが明確で、理解やデバッグが容易です。
3. 少ないメモリ使用量: コンポーネントツリー全体の仮想表現を保持する必要がありません。

トレードオフ：

1. メンタルモデルの転換: React のレンダリングサイクルに慣れた開発者は、「コンポーネントは一度しか実行されない」という新しいモデルに適応する必要があります。
2. エコシステムとの統合: Signals 自体は高性能ですが、巨大な React VDOM エコシステム（たとえば一部の UI ライブラリ）と深く統合するには、追加の適応作業が必要になる場合があります。

まとめ

Signals の復興は、フロントエンドにおける状態管理パラダイムの重要な進化を示しています。開発者の意識を「コンポーネントがどのようにレンダリングされるか」から、より本質的な「状態がどのように流れるか」という問題へと引き戻しました。コンパイラとの深い統合により、Signal は優れた開発体験を提供しながら、Web アプリケーションのパフォーマンス限界に新たな可能性をもたらします。

従来のフロントエンドとバックエンドを分離した開発では、APIが両者の「契約」となる。通常は次の方法でこの契約を管理する：

• RESTful API：OpenAPI（Swagger）などのツールを使い、詳しいAPIドキュメントを生成、管理する。
• GraphQL：厳密なSchema Definition Language（SDL）を使い、データ構造と操作を定義する。

これらの方法は有効だが、共通の問題がある。契約と実装が分離していることだ。フロントエンド開発者がAPIを呼び出すとき、そのAPIがドキュメントやスキーマに書かれたデータ構造を返すと信じる。しかしバックエンドの実装が変わり、たとえばフィールド名が変更されたのに、ドキュメントやスキーマが間に合って更新されなければ、その不一致は実行時になって初めて表面化し、バグを引き起こす。

この「契約」を実装と自動的に同期させ、さらにはコンパイル時に不一致を発見する方法はないだろうか？

2. tRPCの中心思想：スキーマではなく型を共有する

tRPC（TypeScript Remote Procedure Call）は、抜本的だが非常に単純な方法を提案する。フロントエンドとバックエンドの両方でTypeScriptを使うなら、型をそのまま共有すればよいのではないか？

tRPCでは、純粋なTypeScript関数をバックエンドAPIとして記述し、フロントエンドから直接呼び出せる。ローカルモジュールの関数を呼ぶように、完全な型推論と自動補完を利用できる。

スキーマにもコード生成にも依存しない。唯一の「契約」はTypeScriptの型そのものである。

3. どのように動くのか？

tRPCの魔法は、型推論と少し巧妙なカプセル化にある。

a. バックエンド：API Routerを定義する

バックエンド（通常はNode.jsサービス）では、tRPCの関数を使って一つ以上の「Router」を作成する。各Routerは、呼び出し可能な「Procedure」、つまりAPIエンドポイントの集合である。

// server/router.ts
import { initTRPC } from '@trpc/server';
import { z } from 'zod'; // 使用 Zod 进行运行时校验

const t = initTRPC.create();

export const appRouter = t.router({
  // 定义一个名为 `getUser` 的查询 procedure
  getUser: t.procedure
    .input(z.object({ userId: z.string() }))
    .query(({ input }) => {
      // 在这里查询数据库或执行其他逻辑
      const user = { id: input.userId, name: 'Alex' };
      return user;
    }),

  // 定义一个名为 `createUser` 的变更 procedure
  createUser: t.procedure
    .input(z.object({ name: z.string() }))
    .mutation(({ input }) => {
      const user = { id: `${Math.random()}`, name: input.name };
      return user;
    }),
});

// 导出 router 的类型定义
export type AppRouter = typeof appRouter;

b. フロントエンド：クライアントを作成してAPIを呼び出す

フロントエンドでは、バックエンドからAppRouterという型だけをインポートすればよい。サーバー側のコードではなく、型だけをインポートしている点が重要だ。

// client/trpc.ts
import { createTRPCReact } from '@trpc/react-query';
import type { AppRouter } from '../server/router'; // 只导入类型

export const trpc = createTRPCReact<AppRouter>();

これでReactコンポーネントから、ローカル関数のようにAPIを呼び出し、完全な型安全性と自動補完を利用できる。

// client/components/UserInfo.tsx
import { trpc } from '../trpc';

function UserInfo({ userId }: { userId: string }) {
  // `useQuery` 的第一个参数是 procedure 的路径
  // 你输入 `trpc.` 时，IDE 会自动提示 `getUser` 和 `createUser`
  const userQuery = trpc.getUser.useQuery({ userId });

  if (userQuery.isLoading) {
    return <div>Loading...</div>;
  }

  // `userQuery.data` 的类型被自动推断为 { id: string; name: string }
  return <div>User: {userQuery.data?.name}</div>;
}

この時点でバックエンド開発者が、getUserの返すnameフィールドをfullNameに変更すると、フロントエンドのuserQuery.data?.nameは実行時を待たず、TypeScriptのコンパイル時にすぐエラーになる。

4. tRPCを選ぶ理由

• 完全なエンドツーエンド型安全性：これが中心的な価値である。API契約の不一致によって発生する一群のバグを取り除ける。
• 優れた開発者体験：IDEの自動補完により、ドキュメントを調べたりAPI構造を推測したりする必要がない。リファクタリングも非常に簡単かつ安全になる。
• コード生成が不要：追加のビルド工程がなく、フィードバックループが極めて速い。
• 軽量で柔軟：tRPC自体は非常に小さく、どのフロントエンドフレームワークやバックエンドサービスとも連携できる。

結論

tRPCは、フルスタックTypeScript開発にこれまでにない滑らかな体験をもたらす。APIドキュメントとスキーマへの依存をなくすことで、フロントエンドとバックエンドの連携をシームレスかつ非常に安全にする。モノレポ構成では、その長所がさらに際立つ。フルスタックTypeScriptアプリケーションを構築しているなら、tRPCは時間をかけて試す価値のある画期的なツールだ。

React、Vue、Svelteなどのモダンなフロントエンドフレームワークは、複雑なWebアプリケーションを構築する開発体験を大きく向上させました。しかし、それらをブログ、ポートフォリオ、ドキュメント、マーケティングサイトの構築に使うと、ある疑問が生じます。主にコンテンツを表示するこれらのサイトで、本当にページ全体をシングルページアプリケーション（SPA）として読み込む必要があるのでしょうか。

答えはたいてい「いいえ」です。この種のサイトでユーザーが最も必要としているのは、コンテンツへ素早くアクセスすることです。JavaScriptが多すぎると、かえって操作可能になるまでの時間（TTI）が遅くなり、ユーザー体験とSEOに悪影響を与えます。

Astroは、まさにこの問題を解決するために生まれました。

2. Astroの中核理念：コンテンツ優先、デフォルトでゼロJS

Astroはモダンな静的サイトジェネレーター（SSG）であり、その中核理念はコンテンツ優先です。できるだけ多くの作業をビルド時に完了し、ブラウザーへ送るJavaScriptを可能な限り少なくすることを目指しています。

そのために、Astroは2つの大きな革新を打ち出しました。

• デフォルトでゼロJavaScript（Zero-JS by Default）：Astroは、React、Vue、Svelteのいずれで書かれていても、すべてのUIコンポーネントをビルド時に純粋なHTMLへレンダリングします。そのためブラウザーが受け取るのは静的ページであり、フレームワークのJSランタイムを読み込む必要がなく、非常に高速に表示できます。
• アイランドアーキテクチャ（Islands Architecture）：これこそがAstroの真髄です。静的HTMLでできた「海」の中で、クライアント側の操作が必要なコンポーネントだけを「島」として指定できます。Astroはそれらの島に必要なJavaScriptを個別にバンドルして読み込み、ページの残りは完全に静的なまま保ちます。

3. 「島」はどのように動くのか？

Astroでは、client:*ディレクティブを追加することで、コンポーネントを対話可能な島として指定できます。

たとえば、Reactで書かれたCounter.jsxというカウンターコンポーネントがあるとします。Astroページでは次のように使用できます。

---
// src/pages/index.astro
import Counter from '../components/Counter.jsx';
---
<html>
  <body>
    <h1>Astro 示例</h1>
    <p>这是一个静态的段落，它不会加载任何 JS。</p>

    {/* 这个组件是一个交互式岛屿 */}
    <Counter client:load />

    <p>这是另一个静态段落。</p>
  </body>
</html>

client:loadディレクティブはAstroに次のことを指示します。

1. サーバー側でCounterコンポーネントの初期HTMLをレンダリングする。
2. Counterコンポーネント用に独立したJSバンドルを作成する。
3. ページ読み込み時にこのJSバンドルを自動で読み込み、コンポーネントを「有効化」（hydrate）して操作可能にする。

Astroには、client:idle（ブラウザーがアイドル状態のときに読み込む）やclient:visible（コンポーネントがビューポートに入ったときに読み込む）など、さらに細かな読み込みディレクティブもあり、パフォーマンス最適化を一段と進められます。

4. フレームワーク非依存

Astroのもう一つの大きな魅力は、UIフレームワークに対する柔軟性です。同じAstroプロジェクト内で、React、Vue、Svelte、SolidJS、Litなど異なるフレームワークのコンポーネントを同時に利用できます。これにより、チームでの協働や技術選定に大きな柔軟性が生まれます。

結論

AstroはReactやVueを置き換えるものではなく、特定の場面により適した解決策を提供するものです。プロジェクトがコンテンツ中心で、パフォーマンスとSEOに非常に高い要件を持つサイトであるなら（たとえば、このブログ自体もAstroで構築されています）、Astroは間違いなく深く探る価値のある優れた選択肢です。静的サイトのパフォーマンス上の利点と、モダンなフレームワークの開発体験を見事に組み合わせています。

2022 年 12 月、Svelte チームは SvelteKit 1.0 のリリースを正式に発表しました。これは Svelte コミュニティだけでなく、フロントエンド分野全体にとっても画期的な出来事です。SvelteKit は、もはや単なる「Svelte 版の Next.js や Nuxt.js」ではありません。独自の設計思想を携え、よりシンプルで柔軟、かつ高性能な Web アプリケーション構築手法を提供することを目指しています。

SvelteKit とは？

Svelte に詳しい方なら、Svelte 自体がコンポーネントフレームワークであることをご存じでしょう。大胆なコンパイラによって、ビルド時に .svelte ファイルを効率的な命令型 JavaScript コードへ変換し、驚異的なパフォーマンスと極めて小さなランタイムオーバーヘッドを実現します。

一方、SvelteKit は Svelte 上に構築されたアプリケーションフレームワークです。ルーティング、サーバーサイドレンダリング（SSR）、データ読み込み、デプロイアダプターなど、完全なアプリケーションの構築に必要なすべてを処理するため、開発者はビジネスロジックの開発に集中できます。

中核機能の概要

1. ファイルシステムベースのルーティング

Next.js と同じように、SvelteKit のルートはファイルシステムの構造から自動的に生成されます。src/routes ディレクトリ以下のファイル構造が、アプリケーションの URL に直接対応します。

• src/routes/+page.svelte -> /
• src/routes/about/+page.svelte -> /about
• src/routes/blog/[slug]/+page.svelte -> /blog/some-post

設定より規約を優先するこの方法により、ルート管理が大幅に簡素化されます。

2. 柔軟なレンダリングモード

SvelteKit では、ページ単位でレンダリング方法を細かく制御できます。サーバーサイドレンダリング（SSR）、静的サイト生成（SSG）、またはその両方を組み合わせた構成を、同じアプリケーション内で実現できます。単一のページだけ SSR を無効にし、純粋なクライアントサイドのシングルページアプリケーション（SPA）にすることさえ可能です。

3. 汎用的な load 関数

SvelteKit はデータ読み込みのパターンを統一します。各ページ（またはレイアウト）と同じディレクトリに +page.js または +page.server.js ファイルを作成し、load 関数をエクスポートできます。

• +page.js の load 関数は、サーバーとクライアントの両方で実行されます。
• +page.server.js の load 関数はサーバー上でのみ実行されるため、データベースや非公開 API へ安全にアクセスできます。

load 関数が返したデータは、対応する +page.svelte コンポーネントへ自動的に渡されます。

// src/routes/blog/[slug]/+page.server.js
import * as db from '$lib/server/database';

export async function load({ params }) {
  const post = await db.getPost(params.slug);
  return { post };
}

4. アダプター

「一度書けば、どこへでもデプロイできる」ことは、SvelteKit の中心的な約束の一つです。アダプターを利用すると、対象とするあらゆるプラットフォームに適した形式でアプリケーションをパッケージ化できます。

• @sveltejs/adapter-node: 従来の Node.js サーバーへのデプロイに使用します。
• @sveltejs/adapter-vercel: Vercel プラットフォームに対応します。
• @sveltejs/adapter-static: アプリケーション全体を静的ファイルとしてプリレンダリングし、あらゆる静的ホスティングで利用できるようにします。
• Netlify や Cloudflare Workers などのプラットフォームに対応する、さらに多くの公式・コミュニティ製アダプターがあります。

まとめ

SvelteKit 1.0 のリリースは、Svelte エコシステムの成熟を示しました。Svelte コンパイラの究極的なパフォーマンスと、入念に設計されたアプリケーションフレームワークを組み合わせ、強力で快適な開発体験を提供します。シンプルな静的ページから複雑な動的アプリケーションまで構築できる万能なフレームワークを探しているなら、SvelteKit は間違いなく試す価値があります。

「状態をどのように美しく管理するか？」これは、プロジェクトが成長する過程ですべての React 開発者が向き合わなければならない中心的な問題です。単純なコンポーネント内部の状態から、複数のコンポーネントにまたがる複雑なグローバル状態まで、React コミュニティはさまざまな解決策を探ってきました。これらの手法の進化は、コンポーネント指向の開発に対する理解が深まってきたことも表しています。

第 1 段階：素朴な時代 — useState と Props Drilling

当初、利用できるのは useState（またはクラスコンポーネントの this.state）だけでした。ある状態を複数のコンポーネントで共有する必要がある場合、React の公式な推奨は 「状態のリフトアップ（Lifting State Up）」 でした。状態をそれらのコンポーネントに最も近い共通の親へ移し、そこから props を通じて状態と更新関数を渡します。

コンポーネントの階層が深くなると、このパターンは 「Props Drilling」 を引き起こします。中間層のコンポーネントが、自身ではまったく利用しない props を、より深い子コンポーネントへ渡すためだけに受け取る状態です。これによってコンポーネント間の結合が強くなり、リファクタリングや保守が難しくなりました。

第 2 段階：公式の回答 — Context API

Props Drilling を解決するため、React は公式に Context API を提供しました。「コンテキスト」を作成し、コンポーネントツリーの上層で値を提供（Provide）すれば、どれほど深い位置の子コンポーネントでも値を直接利用（Consume）でき、階層ごとに手動で渡す必要がなくなります。

// 1. 创建 Context
const ThemeContext = React.createContext('light');

// 2. 在顶层提供值
<ThemeContext.Provider value="dark">
  <App />
</ThemeContext.Provider>

// 3. 在子组件中消费
const theme = useContext(ThemeContext); // 'dark'

しかし、Context API にも「落とし穴」があります。それはパフォーマンスの問題です。Provider の value が変化すると、その Context を利用しているすべてのコンポーネントが再レンダリングされます。たとえ必要なのが value オブジェクトのごく一部だけでも同じです。そのため Context API は、頻繁に変化する複雑なグローバル状態の管理には適していません。

第 3 段階：統一の時代 — Redux

Context API がまだ成熟していなかった時代に Redux が登場し、大規模で複雑なアプリケーションにおける状態管理の事実上の標準へと急速に成長しました。Flux アーキテクチャと関数型プログラミングの考え方を取り入れ、次の原則をもたらしました。

• 信頼できる唯一の情報源（Single Source of Truth）: アプリケーション全体の state を単一の store に保存します。
• State は読み取り専用: state を変更する唯一の方法は action を dispatch することです。
• 変更には純粋関数を使う: Reducer は以前の state と action を受け取り、新しい state を返します。

Redux は予測可能性、強力なデバッグツール（タイムトラベル）、豊富なミドルウェアのエコシステムによって、大規模アプリケーションの状態管理問題を解決しました。しかし、欠点も同じくらい明らかでした。煩雑な ボイラープレート（Boilerplate） です。単純な機能を実現するだけでも Actions、Reducers、Dispatchers を記述する必要があり、開発者の認知的な負担は大きくなりました。

第 4 段階：ルネサンス — 軽量で Hooks-First な手法

React Hooks の普及と Redux の複雑さに対する見直しを背景に、コミュニティでは新しく、より軽量な状態管理ライブラリが次々と登場しました。簡潔な API、単純なメンタルモデル、Hooks の能力を十分に活かすことが共通の特徴です。

Zustand はその優れた代表例です。非常に簡単な create 関数で store を作成でき、次の特徴があります。

• Provider が不要: Store は React コンポーネントツリーの外部に存在し、どこからでもインポートして利用できます。
• 最小限の API: 1 つの Hook だけで状態へのアクセスと更新ができます。
• 選択的な購読による高いパフォーマンス: コンポーネントは必要な state の部分だけを購読でき、Context API のパフォーマンス問題を回避します。

const useStore = create(set => ({
  count: 0,
  inc: () => set(state => ({ count: state.count + 1 })),
}));

function Counter() {
  // 只订阅 count 的变化
  const count = useStore(state => state.count);
  return <h1>{count}</h1>;
}

まとめ：銀の弾丸はない、必要に応じて選ぶ

React 状態管理の変遷は、永続的な「最良の手法」はなく、「現在の状況に最も適した手法」だけがあることを教えてくれます。

• useState: コンポーネントのローカル状態では常に第一の選択肢です。
• Context API: テーマやユーザー認証情報など、頻繁には変化しないグローバルデータの管理に適しています。
• Zustand / Jotai: クライアント側のグローバル状態が必要なほとんどのアプリケーションにとって、パフォーマンスと開発体験の絶妙なバランスを提供します。
• Redux（Redux Toolkit）: 厳格なデータフロー規約、複雑なミドルウェア、強力なデバッグ能力が必要な超大規模アプリケーションでは、今も信頼できる選択肢です。

Webpackは非常に強力で設定の自由度が高いモジュールバンドラーであり、長年にわたってフロントエンドプロジェクトの基盤でした。しかし、プロジェクトの規模が大きくなるにつれ、「バンドル」を中心とする考え方が性能上のボトルネックを生みます。

• 遅いコールドスタート：開発サーバー（dev-server）を起動するたびに、Webpackは依存関係グラフ全体をたどり、すべてのモジュールをメモリ内にバンドルする必要があります。大規模なプロジェクトでは、この処理に数分かかることがあります。
• 遅いホット更新（HMR）：ファイルを変更すると、Webpackは関連するモジュールを再計算して置き換える必要があります。ページ全体の再読み込みよりは速いものの、大規模プロジェクトでは数秒から十数秒遅れることもあり、開発の流れを中断します。

2. Viteはどのように問題を解決するのか？

フランス語で「速い」を意味するViteは、別の道を選びました。モダンブラウザーがネイティブESモジュール（ESM）をサポートしていることを活用し、ビルド工程を2つに分けます。

• 開発時：Viteはサーバーを起動しますが、すべてのモジュールを事前にバンドルしません。代わりにブラウザーからのモジュール要求を受け取り、必要に応じてソースコードを変換して提供します。たとえばブラウザーがmain.jsを要求するとViteがそれを提供し、main.jsがButton.vueをimportするとブラウザーが再び要求を送り、Viteが変換済みのButton.vueを提供します。そのため開発サーバーはほぼ瞬時に起動します。
• 本番時：Viteは同じく効率的なバンドラーであるRollupを使い、高度に最適化された静的アセットを生成します。

この方式は開発体験を一変させ、電光石火の起動とミリ秒単位のホット更新を実現します。

3. 実践的な移行手順

既存のWebpackプロジェクトをViteへ移行する場合、通常は次の手順を行います。

a. 依存関係をインストールし、設定ファイルを作成する

まずViteをインストールします。

pnpm add -D vite @vitejs/plugin-react # 或 @vitejs/plugin-vue

次にプロジェクトのルートにvite.config.jsを作成します。

import react from '@vitejs/plugin-react'
import { defineConfig } from 'vite'

export default defineConfig({
  plugins: [react()],
})

b. index.htmlを移動する

Webpackでは通常、index.htmlをpublicディレクトリに置き、バンドル済みのJSを自動挿入します。Viteはindex.htmlをアプリケーションのエントリーポイントとして扱います。これをプロジェクトのルートへ移し、スクリプト参照を手動で追加する必要があります。

<body>
  <div id="root"></div>
  <script type="module" src="/src/main.jsx"></script>
</body>

c. Webpackプラグインを置き換える

WebpackのLoadersとPluginsに対応するViteプラグインを探す必要があります。コミュニティのエコシステムは豊富で、ほとんどの要件に解決策が見つかります。

d. 環境変数を扱う

Webpackではprocess.env.NODE_ENVを使うことに慣れています。Viteではimport.meta.envを通して環境変数へアクセスする必要があります。たとえばimport.meta.env.VITE_API_URLです。

e. パスエイリアスを設定する

vite.config.jsでのパスエイリアス設定は非常に簡単です。

import path from 'node:path'
// vite.config.js
import { defineConfig } from 'vite'

export default defineConfig({
  // ...
  resolve: {
    alias: {
      '@': path.resolve(__dirname, './src'),
    },
  },
})

4. 移行後の成果

Viteへ移行した後、最も直感的に感じるのは速さです。

• 開発サーバーの起動時間は50秒から2秒に短縮されました。
• ホット更新は平均3〜5秒から、ほとんど感じない数十ミリ秒に短縮されました。
• 設定ファイル（vite.config.js）はwebpack.config.jsより大幅に簡素になりました。

結論

移行中にプロジェクト固有の設定問題へ対処する必要があるかもしれませんが、WebpackからViteへ移ることで開発体験は大きく向上します。まだ遅いビルド処理に耐えているなら、今こそViteを採用する絶好のタイミングです。

styled-components や Emotion などの CSS-in-JS は、JavaScript／TypeScript ファイル内に CSS を記述できるようにし、コンポーネント開発におけるスタイル管理を一変させました。多くの利点があります。

• コンポーネントスコープ: デフォルトでスタイルがコンポーネントに結び付くため、CSS のグローバルな名前衝突を解決します。
• 動的スタイル: コンポーネントの props や state に基づく動的なスタイルを簡単に作成できます。
• コードの同居: スタイルとコンポーネントロジックを同じファイルに置けるため、保守と整理が容易になります。

しかし、これらの利便性にコストがないわけではありません。従来の CSS-in-JS ライブラリの中心には ランタイム（Runtime） があります。コンポーネントがブラウザにマウントされると、CSS-in-JS ライブラリの JavaScript ランタイムは次の処理を行います。

1. テンプレート文字列またはオブジェクト内の CSS を解析します。
2. 一意のクラス名を生成します。
3. ドキュメントの <head> 内にある <style> タグへスタイルを動的に挿入します。

この処理は JavaScript バンドルのサイズを増やし、アプリケーションの起動とレンダリング時に計算コストを加えるため、パフォーマンスに影響します。

2. 「ゼロランタイム」による打開策

実行時パフォーマンスの問題を解決するため、コミュニティは ゼロランタイム（Zero-Runtime）CSS-in-JS という新しい考え方を提案しました。

核となる考え方は、CSS-in-JS の開発体験を残しながら、すべての処理を ビルド時（build time） に完了させることです。通常は Babel プラグインや Vite プラグインであるビルドツールがコードを走査し、CSS-in-JS の使用箇所をすべて見つけて、次の処理を行います。

1. CSS テキストを抽出します。
2. 静的な .css ファイルを生成します。
3. 元の CSS-in-JS コードを、生成された一意のクラス名に置き換えます。

最終的にブラウザへ渡される JavaScript バンドルには CSS-in-JS のランタイムライブラリが一切含まれず、高度に最適化された静的 CSS ファイルを手書きした場合と同じ結果になります。

3. 主なゼロランタイムソリューション

a. Linaria

Linaria はゼロランタイム分野の先駆者の一つです。使い慣れた styled タグ付きテンプレートリテラル構文を使用できます。

// YourComponent.js
import { styled } from '@linaria/react';

const Title = styled.h1`
  font-size: 2rem;
  color: tomato;
`;

// 构建时，这会被转换为：
// <h1 class="Title_a1b2c3d">...</h1>
//
// 并在一个静态 .css 文件中生成：
// .Title_a1b2c3d {
//   font-size: 2rem;
//   color: tomato;
// }

b. vanilla-extract

SEEK 社のチームが開発した vanilla-extract はさらに一歩進み、TypeScript を利用して完全に型安全なスタイルを作成します。すべてのスタイル定義は .css.ts ファイルからエクスポートされる変数であり、強力な型推論と自動補完を提供します。

// styles.css.ts
import { style } from '@vanilla-extract/css';

export const title = style({
  fontSize: '2rem',
  color: 'tomato',
});

c. Panda CSS

Panda CSS は比較的新しい競合です。Tailwind CSS の考え方を取り入れ、「Style Props」による開発体験を提供しながら、ゼロランタイムの出力を保証します。

import { css } from '../styled-system/css';

function MyComponent() {
  return <div className={css({ fontSize: '2rem', color: 'tomato' })} />;
}

4. 利点とトレードオフ

利点:

• 最高のパフォーマンス: 最終成果物は静的 CSS であり、JavaScript ランタイムのコストがありません。
• 小さなバンドルサイズ: クライアントで CSS-in-JS ライブラリを読み込む必要がありません。
• 優れた開発体験: コンポーネントスコープ、TypeScript の型安全性、コードの同居という利点を引き続き得られます。

トレードオフ:

• ビルド時の依存: ビルド工程へ統合する必要があり、設定はやや複雑になります。
• 動的処理の制限: API から得たデータなど、実行時にしか分からない値に基づいてまったく新しいスタイルを生成することはできません。ただし、CSS 変数などの技術でほとんどの動的な場面を補えます。

結論

ゼロランタイム CSS-in-JS は、従来の CSS-in-JS パラダイムを正しい方向へ戻す試みです。「開発時の体験」と「実行時のパフォーマンス」を巧みに分離し、両者の間で難しい妥協をする必要をなくします。最高のパフォーマンスと小さなバンドルサイズを求めるモダン Web アプリケーションにとって、ほぼ完璧なソリューションを提供します。

TC39 委員会の年次リリースプロセスにより、JavaScript 言語は毎年進化を続けています。ECMAScript 2022（ES2022）には、開発者体験とコードの可読性を高めるための新機能が数多く追加されました。なかでも特に注目すべき機能を見ていきましょう。

1. トップレベル await

これは ES2022 で最も期待されていた機能の一つです。従来、await キーワードは async 関数の内部でしか使用できませんでした。そのため、モジュールのトップレベルスコープで非同期処理を扱うのは不便で、通常は IIFE（即時実行関数式）で非同期コードを包む必要がありました。

以前 👎:

// data.js
import { fetchData } from './api.js';

let data;
(async () => {
  data = await fetchData();
  // ... 只能在这里使用 data
})();

export { data }; // 导出时 data 还是 undefined

現在（ES2022）👍:

// data.js
import { fetchData } from './api.js';

const data = await fetchData();

export { data }; // 模块会等待 await 完成后再被其他模块评估

トップレベル await は、モジュールの動的読み込みや依存関係の初期化といった場面を大幅に簡素化し、非同期コードをより直感的に書けるようにします。

2. 配列／文字列のインデックスメソッド .at()

JavaScript で配列の最後の要素を取得するには、通常 arr[arr.length - 1] と書く必要があり、冗長で間違いも起こりやすいものでした。ES2022 では .at() メソッドが導入され、前方と後方のインデックスを統一的に扱えるようになりました。

.at() メソッドは整数を受け取ります。正の数なら対応するインデックスの要素を返し、負の数なら末尾から数えます。

以前 👎:

const arr = [1, 2, 3, 4, 5];
const lastElement = arr[arr.length - 1]; // 5
const secondToLast = arr[arr.length - 2]; // 4

現在（ES2022）👍:

const arr = [1, 2, 3, 4, 5];
const lastElement = arr.at(-1); // 5
const secondToLast = arr.at(-2); // 4

// 同样适用于字符串
const str = 'hello';
console.log(str.at(-1)); // 'o'

3. Object.hasOwn(obj, prop)

オブジェクトが継承されたものではなく独自のプロパティを持つか確認する際は、通常 Object.prototype.hasOwnProperty.call(obj, prop) を使用します。この書き方は非常に煩雑で、Object.create(null) で作られたオブジェクトなど、一部のケースでは問題が起こることもあります。

Object.hasOwn() は、より短く信頼性の高い静的メソッドを提供します。

以前 👎:

const obj = { a: 1 };
console.log(Object.prototype.hasOwnProperty.call(obj, 'a')); // true
console.log(Object.prototype.hasOwnProperty.call(obj, 'toString')); // false

現在（ES2022）👍:

const obj = { a: 1 };
console.log(Object.hasOwn(obj, 'a')); // true
console.log(Object.hasOwn(obj, 'toString')); // false

4. その他の注目すべき機能

• Error Cause: Error コンストラクタが、エラーの「原因」を指定するための第 2 引数を受け取れるようになり、より明確なエラーチェーンを構築しやすくなりました。

  try {
    // ...
  } catch (err) {
    throw new Error('New error message', { cause: err });
  }
  

• RegExp Match Indices（/d フラグ）: /d フラグを使用すると、正規表現の一致結果に各キャプチャグループの開始インデックスと終了インデックスも含まれます。

結論

ES2022 の新機能は革新的な大変化ではありませんが、JavaScript の細部を磨き、開発者が長年抱えてきた多くの問題を解決し、コードをより簡潔で堅牢なものにします。

Redux が React エコシステムで最も有名かつ強力な状態管理ライブラリであることに疑いはありません。単方向のデータフローやタイムトラベルデバッグなどの特性により、大規模で複雑なアプリケーションでは信頼できる選択肢です。しかし、多くの小・中規模プロジェクトにとって、Redux の「ボイラープレート（Boilerplate）」は悩みの種になりがちです。

• Actions & Action Creators: 大量の action の型と作成関数を定義します。
• Reducers: 異なる action を処理するため、大規模な switch 文を記述します。
• Dispatch & Selectors: コンポーネント内で dispatch によって action を送り、useSelector で状態の変化を購読します。
• Context Provider: アプリケーションのルートを <Provider> で包む必要があります。

そのため、単純な状態を一つ追加するだけでも複数のファイルを変更する必要があり、手順が煩雑になります。

2. Zustand：新鮮な選択肢

Zustand（ドイツ語で「状態」）は、react-three-fiber の作者である Poimandres チームが開発した軽量な状態管理ライブラリです。その設計思想はミニマルで非侵襲的であることです。

中核的な特徴：

• コード量が非常に少ない: ある機能を実装するとき、Zustand のコード量は通常 Redux のごく一部です。
• Hooks ベース: すべてが 1 つのカスタム Hook を中心に構成されており、現代的な React 開発の習慣に沿っています。
• Context Provider が不要: アプリケーションの上層を Provider で包む必要はありません。Store はコンポーネントツリーから独立し、どこからでもインポートして利用できます。
• 習得が容易: API が非常にシンプルで、中核的な使い方を数分で学べます。

3. 中核的な使い方

Zustand の利用は、Store の作成とコンポーネントでの利用という 2 つの手順に分かれます。

a. Store を作成する

store はどの .js または .ts ファイルにも定義できます。

// src/store.js
import { create } from 'zustand';

const useBearStore = create((set) => ({
  bears: 0,
  increasePopulation: () => set((state) => ({ bears: state.bears + 1 })),
  removeAllBears: () => set({ bears: 0 }),
}));

export default useBearStore;

create 関数はコールバックを受け取り、その引数が set 関数（React の setState に似た関数）です。ここで状態と、状態を更新するメソッドを定義します。

b. コンポーネントで利用する

どのコンポーネントでも、通常の Hook と同じように使えます。

// src/components/BearCounter.jsx
import useBearStore from '../store';

function BearCounter() {
  const bears = useBearStore((state) => state.bears);
  return <h1>{bears} around here ...</h1>;
}

セレクタ関数 (state) => state.bears を使い、bears の状態を購読している点に注目してください。これにより、コンポーネントは bears が変化したときだけ再レンダリングされるため、不要なパフォーマンスコストを避けられます。

// src/components/Controls.jsx
import useBearStore from '../store';

function Controls() {
  const increasePopulation = useBearStore((state) => state.increasePopulation);
  return <button onClick={increasePopulation}>one up</button>;
}

action の取得も同じように簡単です。

4. 非同期 Action

Zustand は非同期処理も非常に自然に扱えます。redux-thunk や redux-saga のようなミドルウェアは必要ありません。

const useAsyncStore = create((set) => ({
  data: null,
  fetchData: async (url) => {
    const response = await fetch(url);
    const data = await response.json();
    set({ data });
  },
}));

まとめ

Zustand は Redux を完全に置き換えようとするものではありません。厳格な規約、追跡可能性、巨大なエコシステムという点では、Redux に今も優位性があります。

しかし、大多数の React アプリケーションにとって、Zustand はよりシンプルかつ高速で、認知的な負担が少ない選択肢を提供します。Redux の煩雑な手続きに疲れている場合や、次のプロジェクトで軽快かつ柔軟な状態管理ライブラリが必要な場合、Zustand は間違いなく試す価値のある優れた選択肢です。

Monorepo（単一コードリポジトリ）は、複数の独立したプロジェクトやパッケージを1つのコードリポジトリに保存する戦略です。各プロジェクトが個別のリポジトリを持つPolyrepo方式と比べて、Monorepoにはいくつかの大きな利点があります。

• コード共有：異なるプロジェクト間でコンポーネント、ユーティリティ関数、型定義を非常に簡単に共有できます。
• アトミックなコミット：1つの機能変更が複数のパッケージに関係する場合でも、1回のコミットで完了でき、バージョンの一貫性を保てます。
• 依存関係管理の簡素化：すべてのプロジェクトが1つのnode_modulesを共有するか、pnpm/yarn workspaceで最適化するため、依存関係の競合やバージョンの不一致を減らせます。

しかしリポジトリが大きくなると、Monorepoにはビルド性能という課題も生じます。

2. Monorepoの悩み

リポジトリにdocs、webapp、そして共有のuiコンポーネントライブラリがあると想像してください。docsの誤字を1つ直しただけなのに、webappやuiを含むリポジトリ内の全プロジェクトが再ビルド、再テストされることは最も避けたいはずです。

Lernaなど従来のMonorepo管理ツールは、タスクのオーケストレーションやビルドキャッシュに不十分な点があり、次の問題につながります。

• 作業の重複：コードの大部分が変わっていなくても、CI/CDを実行するたびにすべてを最初からビルドし、テストします。
• 長いビルド時間：複数のCPUコアを活用してタスクを効率よく並列実行できません。
• 複雑なスクリプト：タスクの実行順序を手動で制御するために、複雑なpackage.jsonスクリプトを書く必要があります。

3. Turborepo：速度のために生まれた

TurborepoはJavaScript/TypeScriptのMonorepo向けに設計された高性能ビルドシステムで、後にVercelに買収されました。増分ビルドとリモートキャッシュという2つの中核技術で、上記の問題を解決します。

a. 増分ビルドとタスクパイプライン

Turborepoでは、ルートのturbo.jsonファイルでタスク間の依存関係を定義できます。

// turbo.json
{
  "$schema": "https://turbo.build/schema.json",
  "pipeline": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": ["dist/**", ".next/**"]
    },
    "test": {
      "dependsOn": ["build"],
      "outputs": []
    },
    "lint": {
      "outputs": []
    },
    "dev": {
      "cache": false
    }
  }
}

• dependsOn: ["^build"]：^記号は、あるパッケージのbuildタスクが、そのパッケージの依存先にあるすべてのbuildタスクに依存することを意味します。Turborepoはこのグラフに基づき、最も効率的な並列順序でタスクを実行します。
• outputs：そのタスクがどの出力ファイルを生成するかをTurborepoに伝えます。

pnpm turbo buildを実行すると、Turborepoは変更されたファイルを計算し、影響を受けたパッケージだけを再ビルドします。パッケージのソースコードと依存関係が変わっていなければ、Turborepoは前回のビルド成果物をそのまま使うため、処理は一瞬です。

b. リモートキャッシュ

これはTurborepoの「キラー機能」です。ローカルマシンにビルド結果をキャッシュするだけでなく、Vercelや独自のS3バケットなど、共有リモートサーバーへキャッシュをアップロードできます。

つまり、次のことが可能です。

• 同僚が最新のコードを取得した後、その人が必要とする部分をあなたがすでにビルドしていれば、ローカルで再ビルドせずにキャッシュを直接ダウンロードできます。
• CI/CDサーバーもこのリモートキャッシュに接続できます。あるPRがCIでビルドされキャッシュされれば、他の開発者や後続のCIタスクがその成果をすぐに利用できます。

これにより、チーム全体のビルド時間を数十分から数分、さらには数十秒まで短縮できます。

結論

TurborepoがMonorepoを発明したわけではありませんが、高度なキャッシュとタスクスケジューリングシステムを導入することで、Monorepoの開発体験を大幅に改善し、最も重要な性能上のボトルネックを解決しました。Monorepoアーキテクチャを使用している、または採用を考えているなら、Turborepoはあなたとチームの多くの時間を節約できる強力なツールです。

React が仮想 DOM（Virtual DOM）を普及させて以来、VDOM はモダンなフロントエンドフレームワークの標準装備になったかのようです。メモリ上に仮想的な UI 表現を保持し、diff アルゴリズムで最小限の DOM 更新を計算することで、開発体験と多くの場面でのパフォーマンスを向上させます。

しかし、VDOM にコストがないわけではありません。それ自体がメモリを消費し、diff 処理にも計算コストがかかります。そこで一つの疑問が生まれます。VDOM を介さず、状態の変化を DOM に直接かつ正確に反映しながら、宣言的で React に似た開発体験を維持できるのでしょうか。

SolidJS はその答えを示しています。

2. SolidJS の核心：細粒度リアクティビティ（Fine-Grained Reactivity）

SolidJS は宣言的でリアクティブな JavaScript フレームワークです。JSX を使用するため React とよく似ていますが、その内部原理はまったく異なります。

SolidJS のコンパイラは JSX コードを最適なネイティブ DOM 操作へ変換します。VDOM は使用せず、リアクティブな「シグナル」（Signals）で構成される依存グラフを作ります。シグナルの値が変わると、そのシグナルを購読している「エフェクト」（Effects）または計算（Memos）だけが再実行されます。

常識を覆すメンタルモデル：コンポーネントは一度しか実行されない！

React では state や props が変化すると、コンポーネント関数全体が再実行されます。しかし SolidJS では、コンポーネント関数は 最初から最後まで一度しか実行されません。

import { createSignal } from 'solid-js';

function Counter() {
  console.log('Component function runs!'); // 这句话只会在组件挂载时打印一次

  const [count, setCount] = createSignal(0);

  const increment = () => setCount(count() + 1);

  return (
    <button type="button" onClick={increment}>
      Count: {count()}
    </button>
  );
}

ボタンをクリックすると、count() シグナルの読み取り部分と、それに依存する DOM テキストノードだけが更新されます。Counter 関数自体は再実行されません。この「外科手術のような」更新こそが、SolidJS の卓越したパフォーマンスの源です。

3. 主要 API

SolidJS のリアクティブシステムは、主に三つの基本プリミティブで構成されています。

• createSignal(initialValue): リアクティブなシグナルを作成し、getter と setter を返します。[count, setCount]
• createEffect(() => {}): 「エフェクト」を作成します。内部で読み取られたすべてのシグナルを自動的に追跡し、そのいずれかが変化すると再実行されます。DOM を手動で操作するなどの副作用に適しています。
• createMemo(() => {}): キャッシュされる派生計算値を作成します。内部で依存するシグナルが変化したときだけ再計算されます。

import { createSignal, createEffect } from 'solid-js';

function App() {
  const [firstName, setFirstName] = createSignal('John');
  const [lastName, setLastName] = createSignal('Smith');

  // createEffect 会在 firstName 或 lastName 变化时自动运行
  createEffect(() => {
    console.log(`Full name: ${firstName()} ${lastName()}`);
  });

  // ...
}

4. SolidJS を選ぶ理由

• 卓越したパフォーマンス: さまざまな独立ベンチマークで SolidJS は上位に入ることが多く、ネイティブ JavaScript コードに非常に近い性能を示します。
• 非常に小さなバンドルサイズ: VDOM ランタイムがないため、コアパッケージは非常に小さくなっています。
• 慣れ親しんだ開発体験: React Hooks に慣れていれば、SolidJS をすぐに使い始められます。JSX とリアクティブプリミティブの組み合わせは強力で直感的です。
• 真のリアクティビティ: そのモデルは MobX や Vue の Composition API に近いものですが、コンパイラによって実行時コストなしで実現されています。

結論

SolidJS はフロントエンドフレームワークの進化における重要な方向性を示しています。つまり、コンパイラによってビルド時により多くの処理を行い、実行時コードを減らしてパフォーマンスを高めるという方向です。宣言的な開発体験を犠牲にせず、仮想 DOM の制約から完全に離れられることを証明しています。最高のパフォーマンスを求めるアプリケーションにとって、SolidJS は非常に魅力的な選択肢です。

Fetch API は古い XMLHttpRequest に代わり、ブラウザで HTTP リクエストを行う標準的な手段になりました。Promise を基盤とし、より簡潔で強力なリクエスト機能を提供します。

しかし、Fetch API には標準でリクエストを直接キャンセルする仕組みがありません。多くの場面で、リクエストのキャンセルは非常に重要です。

• パフォーマンスの最適化: ユーザーがページを素早く切り替えたり検索語を入力したりするとき、古くなって不要になったリクエストをキャンセルすれば、帯域幅とサーバー資源を節約できます。
• 競合状態の回避: 「入力しながら検索」する場面では、古いリクエストが新しいリクエストより遅く返ると、UI に古いデータが表示される可能性があります。
• メモリリークの防止: コンポーネントのライフサイクル内で開始したリクエストが完了する前にコンポーネントがアンマウントされると、存在しないコンポーネントを更新しようとしてエラーやメモリリークが起きる可能性があります。

2. AbortController：汎用的なキャンセルシグナル

AbortController は、1 つまたは複数の Web リクエストを中止する仕組みを提供する汎用的な Web API です。Fetch API とは独立していますが、Fetch と完全に連携できます。

AbortController の基本的な考え方は次のとおりです。

1. AbortController のインスタンスを作成します。
2. そのインスタンスから AbortSignal オブジェクトを取得します。
3. AbortSignal を、fetch など中止可能な Web API に渡します。
4. キャンセルが必要になったら、AbortController インスタンスの abort() メソッドを呼び出します。

3. AbortController と Fetch の組み合わせ

例を通して、AbortController で Fetch リクエストをキャンセルする方法を見てみましょう。

const controller = new AbortController();
const signal = controller.signal; // 获取信号对象

async function fetchDataWithCancellation(url) {
  try {
    console.log('Fetching data...');
    const response = await fetch(url, { signal }); // 将信号传递给 fetch
    const data = await response.json();
    console.log('Data received:', data);
    return data;
  } catch (error) {
    if (error.name === 'AbortError') {
      console.log('Fetch request was aborted.');
    } else {
      console.error('Fetch error:', error);
    }
  }
}

// 示例用法
const promise = fetchDataWithCancellation('https://jsonplaceholder.typicode.com/posts/1');

// 假设在 500 毫秒后，我们决定取消这个请求
setTimeout(() => {
  controller.abort(); // 调用 abort() 方法取消请求
  console.log('Request aborted by timeout.');
}, 500);

controller.abort() が呼び出されると、fetch リクエストは直ちに中止され、AbortError がスローされます。このエラーを catch ブロックで捕捉し、error.name === 'AbortError' を確認することで、キャンセル操作とその他のネットワークエラーを区別する必要があります。

4. 実際の利用場面

a. 入力しながら検索（Search-as-you-type）

ユーザーが検索ボックスへ素早く入力すると、入力のたびに新しいリクエストが発生する可能性があります。直前の未完了リクエストをキャンセルし、最新のリクエストだけを残せます。

let currentController = null;

document.getElementById('searchInput').addEventListener('input', (event) => {
  if (currentController) {
    currentController.abort(); // 取消上一个请求
  }
  currentController = new AbortController();
  const signal = currentController.signal;

  const query = event.target.value;
  if (query.length > 2) {
    fetchDataWithCancellation(`/api/search?q=${query}`, signal);
  }
});

b. コンポーネントのアンマウント時にリクエストをキャンセル

React や Vue などのフレームワークでは、コンポーネントがアンマウントされるときに、その内部で開始した未完了のリクエストをキャンセルすることで、メモリリークや不要な UI 更新を効果的に防げます。

// React 示例
useEffect(() => {
  const controller = new AbortController();
  fetchDataWithCancellation('/api/data', controller.signal);

  return () => {
    controller.abort(); // 组件卸载时取消请求
  };
}, []);

まとめ

AbortController は現代の Web 開発に欠かせないツールです。Fetch API やその他の非同期処理にネイティブなキャンセル機構を提供し、より堅牢で効率的、かつ優れたユーザー体験を持つアプリケーションの構築に役立ちます。AbortController の使い方を身につけることは、優れたフロントエンド開発者になるために必要なスキルの一つです。