React Labs: What We've Been Working On – February 2024

React Labsの投稿では、活発な研究開発中のプロジェクトについて書いています。前回の更新以来、大きな進歩を遂げており、その進捗を共有したいと思います。

React Compiler

React Compilerはもはや研究プロジェクトではありません。コンパイラは現在instagram.comの本番環境で稼働しており、Metaの追加のサーフェスにコンパイラを展開し、最初のオープンソースリリースの準備を進めています。

前回の投稿で議論したように、Reactは状態が変更されたときに過度に再レンダリングすることがあります。Reactの初期から、このようなケースに対する私たちの解決策は手動メモ化でした。現在のAPIでは、これはuseMemo、useCallback、memoのAPIを適用して、状態変更時にReactがどの程度再レンダリングするかを手動で調整することを意味します。

しかし、手動メモ化は妥協案です。コードを煩雑にし、間違いやすく、最新の状態を保つために追加の作業が必要です。手動メモ化は合理的な妥協案ですが、私たちは満足していませんでした。

私たちのビジョンは、Reactのコアメンタルモデルを損なうことなく、状態が変更されたときにUIの適切な部分だけを自動的に再レンダリングすることです。私たちは、Reactのアプローチ（標準的なJavaScriptの値とイディオムを使った、状態の単純な関数としてのUI）が、多くの開発者にとってReactが親しみやすい理由の重要な部分だと信じています。そのため、私たちはReact用の最適化コンパイラの構築に投資してきました。

JavaScriptは、その緩いルールと動的な性質により、最適化が非常に困難な言語として知られています。React Compilerは、JavaScriptのルールと「Reactのルール」の両方をモデル化することで、コードを安全にコンパイルできます。例えば、Reactコンポーネントは冪等でなければならず（同じ入力に対して同じ値を返す）、propsや状態の値を変更してはいけません。これらのルールは開発者ができることを制限しますが、コンパイラが最適化するための安全な空間を切り開くのに役立ちます。

もちろん、開発者が時々ルールを少し曲げることがあることを理解しており、私たちの目標はReact Compilerができるだけ多くのコードで箱から出してすぐに動作するようにすることです。コンパイラは、コードがReactのルールに厳密に従っていない場合を検出しようとし、安全な場合はコードをコンパイルし、安全でない場合はコンパイルをスキップします。このアプローチを検証するために、Metaの大規模で多様なコードベースに対してテストを行っています。

自分のコードがReactのルールに従っていることを確認したい開発者には、Strict Modeを有効にし、ReactのESLintプラグインを設定することをお勧めします。これらのツールは、Reactコードの微妙なバグを捉えるのに役立ち、今日のアプリケーションの品質を向上させ、React Compilerなどの今後の機能に対してアプリケーションを将来対応させます。

私たちはまた、Reactのルールの統合ドキュメントとESLintプラグインの更新に取り組んでおり、チームがこれらのルールを理解し、より堅牢なアプリを作成するために適用できるよう支援しています。

コンパイラの動作を見るには、昨秋の講演をチェックしてください。講演の時点では、instagram.comの1ページでReact Compilerを試した初期の実験データがありました。それ以来、instagram.com全体でコンパイラを本番環境に出荷しました。また、Metaの追加のサーフェスへの展開を加速し、オープンソース化するためにチームを拡大しました。私たちは今後の道のりに興奮しており、今後数ヶ月でより多くのことを共有する予定です。

Actions

私たちは以前、Server Actionsを使ってクライアントからサーバーにデータを送信するソリューションを探求していることを共有し、データベースの変更を実行してフォームを実装できるようにしました。Server Actionsの開発中に、これらのAPIを拡張してクライアントのみのアプリケーションでのデータ処理もサポートするようにしました。

このより広範な機能のコレクションを、単に「Actions」と呼んでいます。

Actionsを使用すると、<form/>などのDOM要素に関数を渡すことができます：

<form action={search}>
  <input name="query" />
  <button type="submit">Search</button>
</form>

action関数は同期的または非同期的に動作できます。標準的なJavaScriptを使ってクライアント側で定義することも、'use server'ディレクティブを使ってサーバー上で定義することもできます。actionを使用する場合、Reactはデータ送信のライフサイクルを管理し、useFormStatusやuseActionStateなどのフックを提供して、フォームアクションの現在の状態と応答にアクセスできます。

デフォルトでは、Actionsはトランジション内で送信され、アクションが処理されている間も現在のページをインタラクティブに保ちます。Actionsは非同期関数をサポートしているため、トランジションでasync/awaitを使用する機能も追加しました。これにより、fetchなどの非同期リクエストが開始されたときにトランジションのisPending状態で保留中のUIを表示し、更新が適用されるまでずっと保留中のUIを表示できます。

Actionsと並んで、楽観的状態更新を管理するためのuseOptimisticという機能を導入しています。このフックを使用すると、最終状態がコミットされると自動的に元に戻される一時的な更新を適用できます。Actionsの場合、これにより送信が成功すると仮定してクライアント上でデータの最終状態を楽観的に設定し、サーバーから受信したデータの値に戻すことができます。通常のasync/awaitを使用して動作するため、クライアントでfetchを使用している場合でも、サーバーからのServer Actionを使用している場合でも同じように動作します。

ライブラリ作成者は、useTransitionを使用して独自のコンポーネントでカスタムaction={fn}プロパティを実装できます。私たちの意図は、ライブラリがコンポーネントAPIを設計する際にActionsパターンを採用し、React開発者に一貫した体験を提供することです。例えば、ライブラリが<Calendar onSelect={eventHandler}>コンポーネントを提供している場合、<Calendar selectAction={action}>APIも公開することを検討してください。

私たちは最初、クライアント・サーバー間のデータ転送のためのServer Actionsに焦点を当てていましたが、Reactに対する私たちの哲学は、すべてのプラットフォームと環境で同じプログラミングモデルを提供することです。可能な場合、クライアントで機能を導入すると、サーバーでも動作するようにし、その逆も同様です。この哲学により、アプリがどこで実行されても動作する単一のAPIセットを作成でき、後で異なる環境にアップグレードすることが容易になります。

Actionsは現在Canaryチャンネルで利用可能で、Reactの次のリリースで出荷される予定です。

React Canaryの新機能

私たちは、設計が最終に近づいた個々の新しい安定機能を、安定したsemverバージョンでリリースされる前にできるだけ早く採用するオプションとしてReact Canariesを導入しました。

Canariesは、私たちがReactを開発する方法の変更です。以前は、機能はMeta内部で非公開で研究・構築されていたため、ユーザーはStableにリリースされたときに最終的な洗練された製品のみを見ることができました。Canariesでは、React Labsブログシリーズで共有する機能を最終化するために、コミュニティの助けを借りて公開で構築しています。これは、機能が完了した後ではなく、最終化されている間に新機能について早く聞くことを意味します。

React Server Components、Asset Loading、Document Metadata、ActionsはすべてReact Canaryに搭載され、react.devでこれらの機能のドキュメントを追加しました：

• Directives："use client"と"use server"は、フルスタックReactフレームワーク用に設計されたバンドラー機能です。これらは2つの環境間の「分割点」をマークします："use client"はバンドラーに<script>タグを生成するよう指示し（Astro Islandsのように）、"use server"はバンドラーにPOSTエンドポイントを生成するよう指示します（tRPC Mutationsのように）。これらを組み合わせることで、クライアント側のインタラクティビティと関連するサーバー側ロジックを組み合わせた再利用可能なコンポーネントを書くことができます。

• Document Metadata：コンポーネントツリーのどこでも<title>、<meta>、メタデータ<link>タグをレンダリングするための組み込みサポートを追加しました。これらは、完全にクライアント側のコード、SSR、RSCを含むすべての環境で同じように動作します。これにより、React Helmetなどのライブラリによって開拓された機能の組み込みサポートが提供されます。

• Asset Loading：スタイルシート、フォント、スクリプトなどのリソースの読み込みライフサイクルとSuspenseを統合し、<style>、<link>、<script>などの要素内のコンテンツが表示準備ができているかどうかをReactが判断できるようにしました。また、リソースがいつ読み込まれ初期化されるべきかをより詳細に制御するためのpreloadやpreinitなどの新しいResource Loading APIも追加しました。

• Actions：上記で共有したように、クライアントからサーバーへのデータ送信を管理するためのActionsを追加しました。<form/>などの要素にactionを追加し、useFormStatusでステータスにアクセスし、useActionStateで結果を処理し、useOptimisticでUIを楽観的に更新できます。

これらの機能はすべて連携して動作するため、Stableチャンネルで個別にリリースすることは困難です。フォーム状態にアクセスするための補完的なフックなしでActionsをリリースすると、Actionsの実用的な使いやすさが制限されます。Server Actionsを統合せずにReact Server Componentsを導入すると、サーバー上でのデータ変更が複雑になります。

機能セットをStableチャンネルにリリースする前に、それらが結束して動作し、開発者が本番環境で使用するために必要なすべてを持っていることを確認する必要があります。React Canariesにより、これらの機能を個別に開発し、機能セット全体が完了するまで安定したAPIを段階的にリリースできます。

React Canaryの現在の機能セットは完了しており、リリースの準備ができています。

Reactの次のメジャーバージョン

数年の反復を経て、react@canaryはreact@latestに出荷する準備が整いました。上記で言及した新機能は、アプリが実行されるあらゆる環境と互換性があり、本番使用に必要なすべてを提供します。Asset LoadingとDocument Metadataは一部のアプリにとって破壊的変更となる可能性があるため、Reactの次のバージョンはメジャーバージョンになります：React 19。

リリースの準備にはまだやるべきことがあります。React 19では、Web Componentsのサポートなど、破壊的変更を必要とする長年要求されていた改善も追加しています。現在の私たちの焦点は、これらの変更を実装し、リリースの準備をし、新機能のドキュメントを最終化し、含まれる内容の発表を公開することです。

React 19に含まれるすべて、新しいクライアント機能の採用方法、React Server Componentsのサポートを構築する方法について、今後数ヶ月でより多くの情報を共有する予定です。

Offscreen（Activityに改名）

前回の更新以来、私たちが研究している機能を「Offscreen」から「Activity」に改名しました。「Offscreen」という名前は、アプリの見えない部分にのみ適用されることを示唆していましたが、機能を研究している間に、モーダルの後ろのコンテンツなど、アプリの一部が見えているが非アクティブである可能性があることに気づきました。新しい名前は、アプリの特定の部分を「アクティブ」または「非アクティブ」とマークする動作をより正確に反映しています。

Activityはまだ研究中で、残りの作業はライブラリ開発者に公開されるプリミティブを最終化することです。より完成度の高い機能の出荷に焦点を当てている間、この分野の優先度を下げています。

その他

この更新に加えて、私たちのチームは会議で発表し、ポッドキャストに出演して私たちの作業についてより多く語り、質問に答えています。

• Sathya GunasekaranがReact IndiaカンファレンスでReact Compilerについて講演しました
• Dan AbramovがRemixConfで「React from Another Dimension」というタイトルの講演を行い、React Server ComponentsとActionsがどのように作られた可能性があるかの代替歴史を探求しました
• Dan AbramovがChangelogのJS PartyポッドキャストでReact Server Componentsについてインタビューを受けました
• Matt CarrollがFront-End FireポッドキャストでインタビューされThe Two Reactsについて議論しました

この投稿をレビューしてくれたLauren Tan、Sophie Alpert、Jason Bonta、Eli White、Sathya Gunasekaranに感謝します。

読んでいただきありがとうございます。React Confでお会いしましょう！