このブログはアーカイブされています。最新の記事は ja.react.dev/blog でご覧ください。

React 18 の完成は数年がかりの仕事であり、React チームはそこから貴重な教訓を得ることになりました。このリリースは何年も研究を行い、様々なアプローチを試した結果として生まれたものです。いくつかのアプローチはうまく行った一方で、多くは行き詰まって新たな知見のみをもたらすことになりました。ここから我々が学んだことは、我々がどんなことを試しているのかをコミュニティに知らせることなくただお待たせするというのは、フラストレーションの元だ、ということです。

我々は、かなり実験的なものから明確に定義されているものまで、ほぼ常に様々なプロジェクトを同時に進めています。今後は、これらのプロジェクトに関する我々の取り組みについて、より多くのことを定期的にコミュニティと共有していくようにしたいと思います。

あらかじめ申しあげておくと、この記事は明確なタイムラインのあるロードマップではありません。以下に挙げるプロジェクトの多くはまだ活発に探求中のものであり、具体的なリリース日を設定することは困難です。我々の学びの結果次第では、そもそも現在のイテレーションではリリースされないという可能性すらあります。その代わりここでは、現在まさに我々が何を問題と考えており、現時点でどこまでを学んだのかについて、共有していきたいと思います。

サーバコンポーネント

2020 年 12 月に、React サーバコンポーネント (RSC) に関する実験的なデモを発表しました。それ以降、必要となる準備作業を React 18 で済ませ、実験のフィードバックから得られた改善に取り組んできました。

特に、I/O ライブラリをフォークして例えば react-fetch のようなものを作成していく、というアイディアは捨て去ることにし、代わりに互換性のために async/await モデルを採用することにします。データフェッチングにはルータを使うこともできるのでこれにより RSC のリリースが遅れるということはありません。もうひとつの変更は、ファイルの拡張子でサーバコンポーネントかどうかを区別するというアプローチをやめ、区別を注釈で行うことにする、というものです。

Webpack と Vite の両方で振る舞いが同じになるようバンドラのサポートを共通化することについて、Vercel および Shopify とともに取り組んでいます。リリース前に、React のエコシステム全体で RSC の振る舞いが同じになるようにしたいと考えています。この部分が安定化前の最大の障壁となっています。

アセットのロード

現在のところ、スクリプトや外部スタイル・フォント・画像のようなアセットは、典型的には外部のシステムを通じてプリロードあるいはロードされています。しかしこれにより、ストリーミングやサーバコンポーネントといった新たな環境でうまく動くようにするのが難しくなることがあります。 あらゆる React の環境で動作する API を追加し、それを通じて外部に分離されたアセットをプリロードあるいはロードできるよう、検討を進めています。

また、この新たな API がサスペンスをサポートすることで、画像や CSS やフォントを使っても、これらがロードされるまで表示はブロックするがストリーミングや並列レンダーはブロックしない、というようにしたいと考えています。これにより、画面上の要素がポップしレイアウトがずれるという「ポップコーン」現象を防ぐことができます。

サーバレンダリングの静的な最適化

Static Site Generation (SSG) と Incremental Static Regeneration (ISR) はキャッシュ可能なページにおいてパフォーマンスを向上するための素晴らしい手法です。が、ダイナミックなサーバサイドレンダリング (SSR) についてもパフォーマンス改善のために何らかの機能を追加できるのではと考えています。特に、全コンテンツのキャッシュはできないが大部分は可能という状況について検討しています。コンパイルや静的パスを用いてサーバレンダリングを最適化する方法について、探索を行っています。

React 最適化コンパイラ

React Conf 2021 において、React Forget についてのアーリープレビューをお届けしました。これは、React のプログラミングモデルを保ちつつ、useMemo や useCallback の同等物を自動で作成して再レンダーのコストを最小化するためのコンパイラです。

最近になって、このコンパイラの安定性と機能を向上するための書き直しが完了しました。新しいアーキテクチャは、ローカルでの変数書き換えのような、より複雑なパターンも解析してメモ化を適用することが可能であり、単にメモ化用フックと同じ事ができるという以上に、様々なコンパイル時最適化の可能性を開くことができます。

また、このコンパイラの様々な機能について試すためのプレイグラウンドを作成しています。プレイグラウンドの主目的はコンパイラ自体の開発をやりやすくすることですが、コンパイラを試して何をやっているのか直観で理解できるようにすることにも役立つと考えています。これにより裏で何をやっているのか洞察できるようになりますし、タイプして即座にコンパイル出力を見ることもできるようになります。こちらはコンパイラのリリースの際に同時にリリースされる予定です。

オフスクリーン

現在のところ、コンポーネントを非表示にしたり表示したりしたい場合、選択肢はふたつあります。ひとつは、ツリーから完全に削除するというものです。これによる問題は、アンマウントするたびに UI の state や、DOM 内に保持されているスクロール位置のような状態が失われてしまうことです。

もうひとつの選択肢は、コンポーネントをマウントしたままで CSS を使って表示・非表示を切り替える、というものです。これにより UI の state は保持されますが、React は非表示のコンポーネントやその子コンポーネントに更新があったときにそれをレンダーし続ける必要があるため、パフォーマンス面ではコストがかかります。

オフスクリーン (offscreen) 機能は第 3 の選択肢を提供します。UI を見た目に非表示とした上で、内容の更新の優先度を下げるのです。これは考え方の点では content-visibility CSS プロパティと似ています。コンテンツが非表示の場合、UI 内の他の要素と同期をとる必要はありません。React はレンダー作業を、アプリがアイドル状態になるかコンテンツが再び表示されるようになるまで遅延させることができます。

オフスクリーン機能は、高レベルの機能を実現するための低レベル機能です。startTransition のような React の他の並行レンダー機能と同様ですが、大抵の場合、あなたが直接オフスクリーン API を利用することはありません。代わりに、フレームワークが実装する以下のようなパターンを通じて利用することになるでしょう。

• 即時の画面遷移。現在でもルーティングフレームワークの中にはナビゲーションを高速化するため、リンクをホバーした際などにデータをプリフェッチするものが存在します。オフスクリーン機能を使えば、さらに後続の画面をバックグラウンドでプリレンダーしておくことが可能になります。
• ステートの再利用。同様に、オフスクリーン機能を使うことで、ページやタブを切り替えた時に前の画面の state を保持しておき、切り替えて戻ってきたときに前の状況を復元できるようになります。
• リストのレンダーの仮想化。大きなリストを表示している際に、リスト仮想化を提供するフレームワークでは現在見えているもの以外にも多くの項目をプリレンダーします。オフスクリーン機能を使えば、見えていない項目をリスト内の見えている項目よりも低優先度でプリレンダーすることができるようになります。
• 背景コンテンツ。また、モーダルをオーバーレイで表示している場合の背景要素など、非表示でないコンテンツのレンダー優先度を下げるような関連機能についても検討しています。

トランジションのトレース

現在 React にはプロファイリングのためのツールがふたつ存在します。オリジナルのプロファイラは、プロファイリングセッション中に起こったすべてのコミットについて概要を表示します。それぞれのコミットに対して、レンダーされた全コンポーネントとレンダーにかかった時間も表示します。これと別に、React 18 で導入されたタイムラインプロファイラのベータ版も存在します。これはコンポーネントのスケジュールの変化や React が更新をいつ行うのかについての情報を表示します。これらのプロファイラはいずれも、開発者がコード内のパフォーマンスに関する問題を特定するのに役立ちます。

我々は、文脈なしに個々の遅いコミットやコンポーネントに関する情報だけ分かったところで開発者にとってはさほど役立たない、ということを学びました。知りたい情報は、現に遅いコミットになってしまっている理由の方です。開発者は、ボタンクリック、初回ロード、ページ移動といった特定の操作を追跡してパフォーマンスの悪化を監視し、なぜ操作が遅かったのか、どのように修正するのかを知りたいのです。

この問題を解決するために、以前 Interaction Tracing API の作成を試みたことがありますが、これには根本的な設計の問題があったため、操作が遅い理由を正確に知ることが難しく、場合によっては操作が全く終わらなくなってしまうこともありました。このためこの API は削除せざるを得ませんでした。

現在、この問題を解決するための Interaction Tracing API の新バージョン（startTransition で起動するので Transition Tracing と仮に呼んでいます）に取り組んでいます。

新たな React ドキュメント

昨年、新たな React のドキュメントサイトのベータ版を発表しました。この新たな教材ではフックを優先的に学ぶことができ、新たな図やイラスト、インタラクティブに試せる例やチャレンジ問題が存在します。React 18 のリリースに集中するために作業をしばらくお休みしていましたが、React 18 のリリースも終わりましたので、新ドキュメントの仕上げとリリースに活発に取り組んでいます。

副作用 (effect) は新規ユーザにとっても経験のあるユーザにとっても難しいトピックのひとつだと聞いていますので、現在我々は副作用についての詳細な説明を準備中です。Synchronizing with Effects が一連の記事のうちで最初に公開されているものですが、これからの数週間でより多くが公開される予定です。また副作用についての詳細な記事を書き始めたことで、副作用に関するよくあるパターンの多くは、React に基本機能を加えることでシンプルにできる、ということに気付きました。初期アイディアの一部は useEvent RFC で共有されています。これはまだ初期の研究段階でありアイディアについて見直しをしているところです。RFC にコメントを寄せてくださったコミュニティの方々や、ドキュメントの書き直しに関してフィードバックや貢献をしてくださった方に感謝します。特に新サイトの実装に関して多くのレビューや改善を寄せてくださった Harish Kumar に感謝します。

このブログ記事のレビューをしてくださった Sophie Alpert に感謝します。

このブログはアーカイブされています。最新の記事は ja.react.dev/blog でご覧ください。

React 18 が npm で利用可能になりました！

前回の投稿にて、アプリを React 18 にアップグレードするためのステップバイステップガイドを共有しました。この投稿では、React 18 の新機能や、将来に向けての展望をお伝えします。

この最新のメジャーバージョンには、自動バッチング (automatic batching) のような自動で有効になる機能改善、startTransition のような新たな API、そしてサスペンス (suspense) に対応したストリーミングでのサーバサイドレンダリング機能が含まれています。

React 18 の機能の多くが基盤としているのは新たに加わった並行レンダラ (concurrent renderer) であり、これが強力な新機能群を実現するために裏で働くようになっています。React の並行処理機能はオプトインであり、並行処理機能を使う場合にのみ有効になるものですが、これは皆さんのアプリ作成方法に大きな影響を与えるものであると思っています。

我々は React で並行処理をサポートするために何年ものあいだ研究開発を重ねてきており、特に既存ユーザが段階的に採用できる方法を提供することに関しては注意を払ってきました。昨年の夏に React 18 ワーキンググループを作成し、エキスパートやコミュニティからフィードバックを集め、React のエコシステム全体がスムースにアップグレードできるようにしてきました。

また、React Conf 2021 でも多くのことを共有してきました。

• キーノートでは、素晴らしいユーザ体験を開発者が簡単に構築できるようにするという我々の使命に React 18 がどう関わるのかについて説明しています。
• Shruti Kapoor は React 18 の新機能の使い方についてデモを行っています。
• Shaundai Person はサスペンスを用いたストリーミングサーバレンダリングについての概要を説明しています。

以下が、並行レンダー機能をはじめとする、このリリースで期待される新要素の概要です。

React Native ユーザ向けの注意：React 18 は新たなアーキテクチャの React Native の一部としてリリースされます。詳細についてはこちらの React Conf キーノートを参照してください。

React の並行処理機能とは？

React 18 で加わった中で最も重要なものとはすなわち「並行処理機能」ですが、これはできることなら皆さんが全く考えないで済むのが望ましいことです。ただしアプリケーション開発者にとっては概ねその通りでしょうが、ライブラリのメンテナにとっては話はちょっと複雑かもしれません。

並行処理は、それ自体が何か機能だというわけではありません。これは、同時に UI の複数のバージョンを React が準備しておけるようにするための、新たな裏方のメカニズムです。並行処理機能そのものは実装の詳細 (implementation detail) に過ぎず、それが有用なのはそれで実現できる様々な機能が存在するからこそだ、と考えてください。React は内部の実装において priority queue や multiple buffering などの洗練された手法を用いています。ですがこれらのコンセプトは公開 API のどこにも現れません。

我々が API を設計する際には、開発者に実装の詳細を見せないように努力しています。React 開発者としてみなさんはユーザ体験をどんな見た目にしたいかを考えることに集中し、その見た目をどのように実現するのかは React が受け持ちます。React 開発者が、裏で並行処理機能がどのように働いているのかを知る必要はありません。

しかし、React の並行処理機能は、普通の「実装の詳細」と比べてより重要なものであり、React のコアのレンダリングモデルに対する本質的な変更です。ですので並行処理の動作について詳しく知ることがもの凄く重要ということではないにせよ、どのようなものかについて高レベルの概観を知っておくことは有用かもしれません。

React の並行処理機能の重要な特性は、処理を中断可能であるということです。React 18 にアップグレードしても、何らかの並行処理機能を加えるまでは、更新は React の以前のバージョンと同じく、まとめて、中断されず、かつ同期的にレンダーされます。同期的なレンダーでは、更新のレンダーが始まったら、ユーザが結果を画面で見られるようになるまでそれを中断することはできません。

並行レンダーにおいては、これが必ずしも正しくなくなります。React は更新のレンダーを開始し、途中で一時停止し、後で再開することができます。途中まで終わったレンダーを完全に捨ててしまうこともありえます。レンダーが中断したとしても、React は UI の見た目に一貫性があることを保証します。これを実現するために、React はツリー全体の評価が終わるまで DOM の書き換えをせずに待機します。これにより、React はメインスレッドをブロックせずにバックグラウンドで次の画面を用意しておけるようになります。つまり、大きなレンダー作業の最中でもユーザの入力に UI が即座に反応できるということであり、ユーザ体験がスムースになります。

もう 1 つの例は、state の再利用です。React の並行処理機能により、画面から UI の一部分をいったん削除し、前回の state を再利用しながら後で戻す、ということが可能です。例えば、ユーザがタブを切り替えて画面から離れて戻ってきた場合、React は以前の画面を以前と同様の state で復帰させる必要があります。将来のマイナーリリースにおいて、このパターンを実装した <Offscreen> というコンポーネントを新たに加える予定です。同様に、<Offscreen> を使ってバックグラウンドで新しい UI を用意し、ユーザが表示させようとする前に準備完了にしておく、ということもできるようになるでしょう。

並行レンダーは React における新しいパワフルなツールであり、サスペンス、トランジション、ストリーミング付きサーバーレンダリングといった新たな機能のほとんどはこれを活用して構築されています。しかし React 18 はこの新しい基盤の上に我々が構築しようとしているものの始まりに過ぎません。

並行処理機能の段階的な採用

厳密には、並行レンダーは破壊的変更です。並行レンダーは中断可能なため、それが有効になるとコンポーネントはわずかに異なった動作をします。

我々はテストにおいて、数千のコンポーネントを React 18 のためにアップグレードしました。そこで分かったことは、ほとんどすべての既存のコンポーネントは並行レンダーにおいても「普通に」動作するということです。しかしいくつかのコンポーネントでは移行のための追加作業が必要です。変更は通常小さなものですが、自分のペースで更新作業を行うことも可能です。React 18 の新たなレンダーの挙動は、あなたのアプリ内で新機能を使っている部分でのみ有効化されます。

大まかな移行作業の流れとしては、まず既存コードの挙動を壊さずにアプリが React 18 で動作するようにします。それから自分のペースで並行処理機能を徐々に追加し始めることができます。<StrictMode> を利用すれば、並行処理に関連するバグに開発時に気付きやすいようにできます。strict モードは本番での動作に影響を与えませんが、開発中には追加の警告を表示したり、べき等 (idempotent) であるべき関数を 2 回呼び出したりします。すべての間違いを捕捉することはできませんが、最もよくある間違いを防ぐのに効果的です。

React 18 にアップグレード後、並行処理機能をすぐに使い始めることができます。例えばユーザの入力をブロックせずに画面遷移を行うために startTransition を使うことができます。あるいは高価な再レンダーの頻度を落とすために useDeferredValue を使うことも可能です。

しかし長期的には、あなたのアプリに並行処理を加えるためのメインの方法は、並行処理に対応したライブラリやフレームワークを使うことになるだろうと考えています。ほとんどの場合、あなたが並行処理の API を直接触ることはないはずです。例えば新しい画面に遷移するたびに毎回開発者が startTransition をコールするのではなく、ルータのライブラリがナビゲーションを startTransition で自動でラップするようになるでしょう。

ライブラリがアップグレードされて並行処理機能対応になるまでには、多少時間がかかるかもしれません。並行処理機能をライブラリが活用しやすくするために新しい API を提供しています。当面は、React エコシステムが徐々に移行していくまで、ライブラリメンテナが作業するのをお待ちください。

詳細は、前回の投稿をご覧ください：React 18 アップグレードガイド.

データフレームワークにおけるサスペンス

React 18 では、Relay、Next.js、Hydrogen、Remix のような、使い方の規約がある (opinionated) フレームワークにおいて、データ取得のためのサスペンスを使い始めることができます。単発的なデータ取得にサスペンスを使うことも技術的には可能ですが、現時点では一般的な戦略としてはお勧めしません。

将来的には、上記のようなフレームワークを用いなくてもあなたのデータにサスペンスを使ってアクセスしやすくするため、新たに基本機能を提供するかもしれません。しかしサスペンスは、ルータやデータレイヤ、サーバレンダリング環境といったあなたのアプリのアーキテクチャと深く結合して利用される場合に、最も効果を発揮します。長期的にも、ライブラリやフレームワークが React のエコシステムにおいて重要な働きをすることを期待しています。

React の以前のバージョンと同様、サスペンスはクライアントで React.lazy を使ってコードを分割する際にも利用できます。しかし我々がサスペンスを使って実現したいと構想しているのは、コードのロードよりもずっと多くのことです。目標は、サスペンスのサポートを拡張していき、いずれはサスペンスによるひとつの宣言的なフォールバックが、あらゆる非同期的な操作（コード、データ、画像などのロード）を扱えるようにすることです。

サーバコンポーネントはまだ開発中です

サーバコンポーネント は実装予定の機能であり、クライアントサイドアプリにおけるリッチなインタラクティビティと伝統的なサーバレンダリングによるパフォーマンス改善とを兼ね備えた、クライアント・サーバ両方にまたがるアプリの開発を可能にするものです。サーバコンポーネントは React の並行処理機能と本質的に結合してはいませんが、サスペンスやストリーミングサーバレンダリングのような並行処理機能と併用した際に最もうまく働くようデザインされています。

サーバコンポーネントはまだ実験的機能ですが、18.x のマイナーリリースで初期バージョンをリリースできる見込みです。それまでは、プロポーザルを推し進めて広く採用できる準備が整うよう、Next.js、Hydrogen、Remix のようなフレームワークと協力していきます。

React 18 の新要素

新機能：自動バッチング

バッチングとは React がパフォーマンスのために複数のステート更新をグループ化して、単一の再レンダーにまとめることを指します。自動バッチング以前は、React のイベントハンドラ内での更新のみバッチ処理されていました。promise や setTimeout、ネイティブのイベントハンドラやその他あらゆるイベント内で起きる更新はデフォルトではバッチ処理されていませんでした。自動バッチングにより、これらの更新も自動でバッチ処理されるようになります：

// Before: only React events were batched.
setTimeout(() => {
  setCount(c => c + 1);
  setFlag(f => !f);
  // React will render twice, once for each state update (no batching)
}, 1000);

// After: updates inside of timeouts, promises,
// native event handlers or any other event are batched.
setTimeout(() => {
  setCount(c => c + 1);
  setFlag(f => !f);
  // React will only re-render once at the end (that's batching!)
}, 1000);

詳細については、Automatic batching for fewer renders in React 18 を参照してください。

新機能：トランジション

トランジション（transition; 段階的推移）とは React における新たな概念であり、緊急性の高い更新 (urgent update) と高くない更新 (non-urgent update) を区別するためのものです。

• 緊急性の高い更新とはタイプ、クリック、プレスといったユーザ操作を直接反映するものです。
• トランジションによる更新は UI をある画面から別の画面に段階的に遷移させるものです。

タイプ、クリック、プレスのような緊急性の高い更新は、物理的な物体の挙動に関する我々の直観に反しないよう、即座に反応する必要があり、そうでないと「おかしい」と認識されてしまいます。一方でトランジション内では、ユーザは画面上であらゆる中間の値が見えることを期待していません。

例えば、ドロップダウン内でフィルタを選択した場合、フィルタボタン自体はクリックした瞬間に反応することを期待するでしょう。しかしフィルタの結果は、ボタンの反応とは別に徐々に現れても構いません。小さな遅延は認識できませんし、あって構わないものです。また、前のレンダーが終わっていない段階で再びフィルタを変更した場合、最終的な結果以外は気にしません。

典型的には、最良のユーザ体験のためには、あるひとつのユーザ入力は緊急性の高い更新と高くない更新の両方を引き起こすようにするべきです。input イベント内で startTransition API を用い、React にどの更新の緊急性が高く、どれが「トランジション」なのかを伝えることができます：

import {startTransition} from 'react';

// Urgent: Show what was typed
setInputValue(input);

// Mark any state updates inside as transitions
startTransition(() => {
  // Transition: Show the results
  setSearchQuery(input);
});

startTransition でラップした更新は緊急性の低いものとして扱われ、クリックやキー押下のような緊急性の高い更新がやってきた場合には中断されます。トランジションがユーザによって中断された場合（例えば素早く複数のタイプが起こった場合）、React は完了しないままに古くなったレンダーを破棄して、最後の更新のみレンダーします。

• useTransition: トランジションを開始するためのフックであり、保留中かどうかの状態を追跡するための値も含まれます。
• startTransition: フックが使えない場合にトランジションを開始するためのメソッドです。

トランジションを使うと並行レンダー機能にオプトインし、更新が中断可能になります。また、コンテンツが再サスペンドした場合、バックグラウンドでトランジション中のコンテンツをレンダーしつつ、現在のコンテンツを表示し続けるよう React に伝えます（詳細については サスペンス RFC を参照）。

トランジションのドキュメントはこちら。

サスペンスの新機能

サスペンスにより、コンポーネントツリーの一部がまだ表示できない場合に、ロード中という状態を宣言的に記述できるようになります：

<Suspense fallback={<Spinner />}>
  <Comments />
</Suspense>

サスペンスにより、「UI ロード中状態」というものが、React のプログラミングモデルで宣言的に記述可能な主要コンセプトに昇格します。その上により高レベルな機能を構築していけるようになります。

我々は数年前に機能限定版のサスペンスを導入しました。しかしサポートされているユースケースは React.lazy によるコード分割のみであり、サーバでのレンダーにおいては一切サポートされていませんでした。

React 18 ではサーバ側でのサスペンスのサポートを追加し、並行レンダリング機能を用いてその能力を向上させました。

React 18 におけるサスペンスはトランジション API と併用した場合に能力を発揮します。トランジション中でサスペンドが発生すると、React は既に見えているコンテンツがフォールバックによって隠されてしまわないようにするのです。代わりに、十分なデータがロードされるまでレンダーを遅らせて、望ましくないロード中状態が見えないようにします。

詳しくは、Suspense in React 18 の RFC を参照してください。

新たなクライアントおよびサーバ用のレンダー API

このリリースを機に、クライアントおよびサーバ用に公開している API を再設計することにしました。これにより React 18 の新しい API にアップグレードするまでの間、React 17 の古い API を利用し続けることができるようになります。

React DOM Client

以下の新たな API は react-dom/client からエクスポートされるようになっています：

• createRoot: render したり unmount したりできる新たなルートを作成するための新メソッドです。ReactDOM.render の代わりに利用してください。これを使わないと React 18 の新機能は動作しません。
• hydrateRoot: サーバでレンダーされたアプリをハイドレーションするための新メソッドです。ReactDOM.hydrate の代わりに、新たな React DOM サーバ API と併せて利用してください。これを使わないと React 18 の新機能は動作しません。

createRoot と hydrateRoot のいずれも、onRecoverableError という新たなオプションを受け取るようになっており、レンダーあるいはハイドレーション中に起きたエラーから React が復帰した場合に通知を受けてログを残したい場合に利用できます。デフォルトでは React は reportError か、古いブラウザの場合は console.error を利用します。

React DOM Client のドキュメントはこちら。

React DOM Server

以下の新たな API は react-dom/client からエクスポートされるようになっており、サーバでサスペンスをストリーミングする機能を完全にサポートしています：

• renderToPipeableStream: Node 環境でのストリーミング用。
• renderToReadableStream: Deno や Cloudflare Workers のようなモダンなエッジランタイム環境用。

既存の renderToString メソッドは今後も動作しますが、推奨されません。

React DOM Server のドキュメントはこちら。

Strict モードの新たな挙動

将来的に、React が state を保ったままで UI の一部分を追加・削除できるような機能を導入したいと考えています。例えば、ユーザがタブを切り替えて画面を離れてから戻ってきた場合に、React が以前の画面をすぐに表示できるようにしたいのです。これを可能にするため、React は同じ state を使用してツリーをアンマウント・再マウントします。

この機能により、React の標準状態でのパフォーマンスが向上しますが、コンポーネントは副作用が何度も登録されたり破棄されたりすることに対して耐性を持つことが必要になります。ほとんどの副作用は何の変更もなく動作しますが、一部の副作用は一度しか登録・破棄されないものと想定しています。

この問題に気付きやすくするために、React 18 は strict モードに新しい開発時専用のチェックを導入します。この新しいチェックは、コンポーネントが初めてマウントされるたびに、すべてのコンポーネントを自動的にアンマウント・再マウントし、かつ 2 回目のマウントで以前の state を復元します。

これまでは、React はコンポーネントをマウントして以下のように副作用を作成してきました：

* React がコンポーネントをマウント
  * レイアウト副作用 (layout effect) を作成
  * （通常の）副作用を作成

React 18 の strict モードでは、開発時にコンポーネントがマウントされた場合、React はコンポーネントの即時アンマウント・再マウントをシミュレーションします：

* React がコンポーネントをマウント
    * レイアウト副作用を作成
    * 副作用を作成
* マウントされたコンポーネント内で副作用の破棄をシミュレート
    * レイアウト副作用を破棄
    * 副作用を破棄
* マウントされたコンポーネント内で以前の state を復元し副作用の再生成をシミュレート
    * レイアウト副作用を作成
    * 副作用の作成用コードの実行

state 再利用可能性の保証についてのドキュメントはこちら。

新たなフック

useId

useId はハイドレーション時の不整合を防ぎつつクライアントとサーバで一意な ID を生成するためのフックです。これは主に、一意な ID を必要とするアクセシビリティ API を組み込むようなコンポーネントライブラリで有用なものです。これにより React 17 およびそれ以前から既に存在した問題が解決されますが、React 18 では新しいストリーミング対応のサーバレンダラが HTML を順番通りに送信しなくなるため、この問題はより重要です。こちらのドキュメントを参照。

補足

useId はリスト内の key を作成するのに使うためのものではありません。key はあなたのデータから作成されるべきです。

useTransition

useTransition と startTransition により、一部の更新は緊急性が低いということをマークできるようになります。その他の更新はデフォルトで緊急性が高いものとして扱われます。React は緊急性の高い更新（例えばテキスト入力の更新）が、緊急性の低い更新（例えば検索結果のリストのレンダー）を中断できるようになります。こちらのドキュメントを参照。

useDeferredValue

useDeferredValue により、ツリー内の緊急性の低い更新の再レンダーを遅延させることができます。デバウンス (debounce) に似ていますが、それと比べていくつかの利点があります。遅延時間が固定でないため、最初のレンダーが画面に反映された時点ですぐに遅延されていた方のレンダーを始められるのです。また遅延されたレンダーは中断可能であり、ユーザインプットをブロックしません。こちらのドキュメントを参照。

useSyncExternalStore

useSyncExternalStore は、外部ストアへの更新を強制的に同期的に行うことで、外部ストアが並行読み取りを行えるようにします。これにより外部のデータソースに購読する際に useEffect を使う必要性がなくなるので、React 外部の状態を扱うあらゆるライブラリにとって推奨されるものです。こちらのドキュメントを参照。

補足

useSyncExternalStore はアプリケーションコードではなくライブラリで使用されることを意図しています。

useInsertionEffect

useInsertionEffect は、CSS-in-JS ライブラリがレンダー時にスタイルを注入する際のパフォーマンス上の問題に対処できるようにするための新しいフックです。すでに CSS-in-JS ライブラリを構築しているのでなければ、これを使うことはまずないでしょう。このフックは、DOM が書き換えられた後、レイアウト副作用 (layout effect) が新しいレイアウトを読み込む前に実行されます。これにより React 17 およびそれ以前から既に存在した問題が解決されますが、React 18 では並行レンダー中にブラウザに処理が渡り、そこでレイアウトが再計算される可能性があるため、より重要です。こちらのドキュメントを参照。

補足

useInsertionEffect はアプリケーションコードではなくライブラリで使用されることを意図しています。

アップグレード方法

ステップバイステップのガイド、および破壊的変更・注目すべき変更の全リストについては React 18 アップグレードガイドを参照してください。

Changelog

React

• Add useTransition and useDeferredValue to separate urgent updates from transitions. (#10426, #10715, #15593, #15272, #15578, #15769, #17058, #18796, #19121, #19703, #19719, #19724, #20672, #20976 by @acdlite, @lunaruan, @rickhanlonii, and @sebmarkbage)
• Add useId for generating unique IDs. (#17322, #18576, #22644, #22672, #21260 by @acdlite, @lunaruan, and @sebmarkbage)
• Add useSyncExternalStore to help external store libraries integrate with React. (#15022, #18000, #18771, #22211, #22292, #22239, #22347, #23150 by @acdlite, @bvaughn, and @drarmstr)
• Add startTransition as a version of useTransition without pending feedback. (#19696 by @rickhanlonii)
• Add useInsertionEffect for CSS-in-JS libraries. (#21913 by @rickhanlonii)
• Make Suspense remount layout effects when content reappears. (#19322, #19374, #19523, #20625, #21079 by @acdlite, @bvaughn, and @lunaruan)
• Make <StrictMode> re-run effects to check for restorable state. (#19523 , #21418 by @bvaughn and @lunaruan)
• Assume Symbols are always available. (#23348 by @sebmarkbage)
• Remove object-assign polyfill. (#23351 by @sebmarkbage)
• Remove unsupported unstable_changedBits API. (#20953 by @acdlite)
• Allow components to render undefined. (#21869 by @rickhanlonii)
• Flush useEffect resulting from discrete events like clicks synchronously. (#21150 by @acdlite)
• Suspense fallback={undefined} now behaves the same as null and isn’t ignored. (#21854 by @rickhanlonii)
• Consider all lazy() resolving to the same component equivalent. (#20357 by @sebmarkbage)
• Don’t patch console during first render. (#22308 by @lunaruan)
• Improve memory usage. (#21039 by @bgirard)
• Improve messages if string coercion throws (Temporal.*, Symbol, etc.) (#22064 by @justingrant)
• Use setImmediate when available over MessageChannel. (#20834 by @gaearon)
• Fix context failing to propagate inside suspended trees. (#23095 by @gaearon)
• Fix useReducer observing incorrect props by removing the eager bailout mechanism. (#22445 by @josephsavona)
• Fix setState being ignored in Safari when appending iframes. (#23111 by @gaearon)
• Fix a crash when rendering ZonedDateTime in the tree. (#20617 by @dimaqq)
• Fix a crash when document is set to null in tests. (#22695 by @SimenB)
• Fix onLoad not triggering when concurrent features are on. (#23316 by @gnoff)
• Fix a warning when a selector returns NaN. (#23333 by @hachibeeDI)
• Fix a crash when document is set to null in tests. (#22695 by @SimenB)
• Fix the generated license header. (#23004 by @vitaliemiron)
• Add package.json as one of the entry points. (#22954 by @Jack)
• Allow suspending outside a Suspense boundary. (#23267 by @acdlite)
• Log a recoverable error whenever hydration fails. (#23319 by @acdlite)

React DOM

• Add createRoot and hydrateRoot. (#10239, #11225, #12117, #13732, #15502, #15532, #17035, #17165, #20669, #20748, #20888, #21072, #21417, #21652, #21687, #23207, #23385 by @acdlite, @bvaughn, @gaearon, @lunaruan, @rickhanlonii, @trueadm, and @sebmarkbage)
• Add selective hydration. (#14717, #14884, #16725, #16880, #17004, #22416, #22629, #22448, #22856, #23176 by @acdlite, @gaearon, @salazarm, and @sebmarkbage)
• Add aria-description to the list of known ARIA attributes. (#22142 by @mahyareb)
• Add onResize event to video elements. (#21973 by @rileyjshaw)
• Add imageSizes and imageSrcSet to known props. (#22550 by @eps1lon)
• Allow non-string <option> children if value is provided. (#21431 by @sebmarkbage)
• Fix aspectRatio style not being applied. (#21100 by @gaearon)
• Warn if renderSubtreeIntoContainer is called. (#23355 by @acdlite)

React DOM Server

• Add the new streaming renderer. (#14144, #20970, #21056, #21255, #21200, #21257, #21276, #22443, #22450, #23247, #24025, #24030 by @sebmarkbage)
• Fix context providers in SSR when handling multiple requests. (#23171 by @frandiox)
• Revert to client render on text mismatch. (#23354 by @acdlite)
• Deprecate renderToNodeStream. (#23359 by @sebmarkbage)
• Fix a spurious error log in the new server renderer. (#24043 by @eps1lon)
• Fix a bug in the new server renderer. (#22617 by @shuding)
• Ignore function and symbol values inside custom elements on the server. (#21157 by @sebmarkbage)

React DOM Test Utils

• Throw when act is used in production. (#21686 by @acdlite)
• Support disabling spurious act warnings with global.IS_REACT_ACT_ENVIRONMENT. (#22561 by @acdlite)
• Expand act warning to cover all APIs that might schedule React work. (#22607 by @acdlite)
• Make act batch updates. (#21797 by @acdlite)
• Remove warning for dangling passive effects. (#22609 by @acdlite)

React Refresh

• Track late-mounted roots in Fast Refresh. (#22740 by @anc95)
• Add exports field to package.json. (#23087 by @otakustay)

Server Components (Experimental)

• Add Server Context support. (#23244 by @salazarm)
• Add lazy support. (#24068 by @gnoff)
• Update webpack plugin for webpack 5 (#22739 by @michenly)
• Fix a mistake in the Node loader. (#22537 by @btea)
• Use globalThis instead of window for edge environments. (#22777 by @huozhi)

このブログはアーカイブされています。最新の記事は ja.react.dev/blog でご覧ください。

リリース告知の記事でお伝えしたとおり、React 18 には新たな並行レンダラを用いた機能が加わっており、既存のアプリケーションが段階的に採用できる方法も提供しています。この投稿では、React 18 にアップグレードするためのステップについてご案内します。

React 18 にアップグレードする際に遭遇した問題は報告をお願いします。

React Native ユーザ向けの注意：React 18 のリリースは React Native の将来のバージョンで行います。これは、このブログ記事で紹介する新機能を活用した新たな React Native アーキテクチャに React 18 が依存しているからです。詳細はこちらの React Conf キーノートを参照してください。

インストール

React の最新バージョンをインストールするには：

npm install react react-dom

Yarn をお使いの場合：

yarn add react react-dom

クライアントレンダリング API への変更

まず React 18 をインストールすると、以下のような警告がコンソールに表示されます：

ReactDOM.render is no longer supported in React 18. Use createRoot instead. Until you switch to the new API, your app will behave as if it’s running React 17. Learn more: https://reactjs.org/link/switch-to-createroot

React では複数のルートを管理する際の使い勝手を改善する、新しいルート API を導入しています。新しいルート API によって新しい並行レンダラも有効になるため、並行処理機能にオプトインできるようになります。

// Before
import { render } from 'react-dom';
const container = document.getElementById('app');
render(<App tab="home" />, container);

// After
import { createRoot } from 'react-dom/client';
const container = document.getElementById('app');
const root = createRoot(container); // createRoot(container!) if you use TypeScript
root.render(<App tab="home" />);

unmountComponentAtNode も root.unmount に置き換わりました：

// Before
unmountComponentAtNode(container);

// After
root.unmount();

またレンダー後のコールバックも削除されました。サスペンスを使った場合に、大抵は期待される結果にならないためです：

// Before
const container = document.getElementById('app');
render(<App tab="home" />, container, () => {
  console.log('rendered');
});

// After
function AppWithCallbackAfterRender() {
  useEffect(() => {
    console.log('rendered');
  });

  return <App tab="home" />
}

const container = document.getElementById('app');
const root = createRoot(container);
root.render(<AppWithCallbackAfterRender />);

補足

以前の render のコールバック API に一対一で対応するものは存在せず、ユースケースによって対応は異なります。詳細はワーキンググループの投稿 Replacing render with createRoot を参照してください。

最後に、あなたのアプリでサーバサイドレンダリングとハイドレーションを使用している場合は、hydrate を hydrateRoot にアップグレードしてください：

// Before
import { hydrate } from 'react-dom';
const container = document.getElementById('app');
hydrate(<App tab="home" />, container);

// After
import { hydrateRoot } from 'react-dom/client';
const container = document.getElementById('app');
const root = hydrateRoot(container, <App tab="home" />);
// Unlike with createRoot, you don't need a separate root.render() call here.

詳細はこちらのワーキングループのディスカッションを参照してください。

補足

アップグレード後にアプリが動かなくなった場合は、アプリを <StrictMode> でラップしていないか確認してください。strict モードは React 18 でより厳密になっているため、開発モードで新たに追加されたチェックにあなたのコンポーネントがすべて適合していないのかもしれません。もし strict モードを外したらアプリが動くようになった場合、アップグレード中は外したままにして、指摘された問題を修正してから元に戻す（トップにでもツリーの一部に対してでも）のでも構いません。

サーバレンダリング API への変更

このリリースでは、react-dom/server を刷新し、サーバ側でのサスペンスやストリーミング SSR がフルサポートされるようになりました。この変更の一環として、サーバ側での逐次的なサスペンスのストリーミング処理をサポートしない既存の Node ストリーミング API を非推奨としました。

以下の API を使うと警告が出るようになります：

• renderToNodeStream: 非推奨 ⛔️️

代わりに Node 環境でのストリーミングには以下を使ってください：

• renderToPipeableStream: New ✨

また、Deno や Cloudflare Workers のようなモダンなエッジランタイム環境でサスペンス付き SSR ストリーミングをサポートする、新たな API を導入します：

• renderToReadableStream: New ✨

以下の API はこれからも動作しますが、サスペンスのサポートに制限がつきます：

• renderToString: 制限付き ⚠️
• renderToStaticMarkup: 制限付き ⚠️

最後に、電子メールをレンダーする目的であれば以下の API を引き続き利用できます：

• renderToStaticNodeStream

サーバレンダリング用 API についての詳細は、ワーキンググループの投稿 Upgrading to React 18 on the server と deep dive on the new Suspense SSR Architecture を、また React Conf 2011 での Shaundai Person の発表 Streaming Server Rendering with Suspense をご覧ください。

TypeScript 型定義の変更

プロジェクトで TypeScript を使っている場合、依存の @types/react と @types/react-dom を最新バージョンに更新する必要があります。新たな型はより安全であり、これまで型チェッカに無視されていた問題を捕捉することができます。最も大きな変更は、props を定義する際に children プロパティを明示的に列挙する必要があるということです。例えば：

interface MyButtonProps {
  color: string;
  children?: React.ReactNode;}

型にのみ関連する変更の全リストについては React 18 の型についてのプルリクエスト を参照してください。ライブラリ型についての修正のサンプルへのリンクがあり、コードをどのように調整すればいいか分かるようになっています。自動移行スクリプトを使うことで、あなたのアプリケーションコードをより新しく、より安全な型定義にすばやく移行しやすくなります。

型に関するバグを見つけた場合は、DefinitelyTyped リポジトリで issue を登録してください。

自動バッチング

React 18 はデフォルトでより多くのバッチング (batching) を行うことで、標準状態でのパフォーマンスを改善します。バッチングとは React がパフォーマンスのために複数のステート更新をグループ化して、単一の再レンダーにまとめることを指します。React 18 より前は、React のイベントハンドラ内での更新のみバッチ処理されていました。promise や setTimeout、ネイティブのイベントハンドラやその他あらゆるイベント内で起きる更新はデフォルトではバッチ処理されていませんでした。

// Before React 18 only React events were batched

function handleClick() {
  setCount(c => c + 1);
  setFlag(f => !f);
  // React will only re-render once at the end (that's batching!)
}

setTimeout(() => {
  setCount(c => c + 1);
  setFlag(f => !f);
  // React will render twice, once for each state update (no batching)
}, 1000);

React 18 以降で createRoot を使うと、すべての更新はどこで発生したかに関わらず、自動でバッチ処理されます。つまり、タイムアウト、promise、ネイティブイベントハンドラおよびその他のあらゆるイベント内で起きた更新は、React イベントで起こった更新と同様にバッチ処理されます：

// After React 18 updates inside of timeouts, promises,
// native event handlers or any other event are batched.

function handleClick() {
  setCount(c => c + 1);
  setFlag(f => !f);
  // React will only re-render once at the end (that's batching!)
}

setTimeout(() => {
  setCount(c => c + 1);
  setFlag(f => !f);
  // React will only re-render once at the end (that's batching!)
}, 1000);

これは破壊的変更ですが、これによりレンダー処理が軽くなり、したがってアプリのパフォーマンスが向上することが期待されます。自動バッチングからオプトアウトするために flushSync を使うことができます：

import { flushSync } from 'react-dom';

function handleClick() {
  flushSync(() => {
    setCounter(c => c + 1);
  });
  // React has updated the DOM by now
  flushSync(() => {
    setFlag(f => !f);
  });
  // React has updated the DOM by now
}

詳細については、Automatic batching 詳解 を参照してください。

ライブラリ向けの新 API

React 18 ワーキンググループでライブラリメンテナと共同で作業を行い、スタイルや外部ストアといった分野に特有のユースケースで並行レンダー機能をサポートするため、新しい API を作成しました。一部のライブラリは、React 18 をサポートするために以下の API に切り替える必要があるかもしれません：

• useSyncExternalStore は、ストアへの更新を強制的に同期的に行うことで、並行読み取りを外部ストアがサポートできるようにするための新たなフックです。この新しい API は React 外部の状態を扱うあらゆるライブラリにとって推奨されるものです。詳細は useSyncExternalStore 概要および useSyncExternalStore API 詳細を参照してください。
• useInsertionEffect は、CSS-in-JS ライブラリがレンダー時にスタイルを注入する際のパフォーマンス上の問題に対処できるようにするための新しいフックです。すでに CSS-in-JS ライブラリを構築しているのでなければ、これを使うことはまずないでしょう。このフックは、DOM が書き換えられた後、レイアウト副作用 (layout effect) が新しいレイアウトを読み込む前に実行されます。これにより React 17 およびそれ以前から既に存在した問題が解決されますが、React 18 では並行レンダー中にブラウザに処理が渡り、そこでレイアウトが再計算される可能性があるため、より重要です。詳細は Library Upgrade Guide for <style> を参照してください。

React 18 では startTransition、useDeferredValue や useId のような新しい API も導入しており、リリース告知記事にて詳細をお伝えします。

strict モードへの変更

将来的に、React が state を保ったままで UI の一部分を追加・削除できるような機能を導入したいと考えています。例えば、ユーザがタブを切り替えて画面を離れてから戻ってきた場合に、React が以前の画面をすぐに表示できるようにしたいのです。これを可能にするため、React は同じ state を使用してツリーをアンマウント・再マウントします。

この機能により、React の標準状態でのパフォーマンスが向上しますが、コンポーネントは副作用が何度も登録されたり破棄されたりすることに対して耐性を持つことが必要になります。ほとんどの副作用は何の変更もなく動作しますが、一部の副作用は一度しか登録・破棄されないものと想定しています。

この問題に気付きやすくするために、React 18 は strict モードに新しい開発時専用のチェックを導入します。この新しいチェックは、コンポーネントが初めてマウントされるたびに、すべてのコンポーネントを自動的にアンマウント・再マウントし、かつ 2 回目のマウントで以前の state を復元します。

これまでは、React はコンポーネントをマウントして以下のように副作用を作成してきました：

* React がコンポーネントをマウント
  * レイアウト副作用 (layout effect) を作成
  * （通常の）副作用を作成

React 18 の strict モードでは、開発時にコンポーネントがマウントされた場合、React はコンポーネントの即時アンマウント・再マウントをシミュレーションします：

* React がコンポーネントをマウント
    * レイアウト副作用を作成
    * 副作用を作成
* マウントされたコンポーネント内で副作用の破棄をシミュレート
    * レイアウト副作用を破棄
    * 副作用を破棄
* マウントされたコンポーネント内で以前の state を復元し副作用の再生成をシミュレート
    * レイアウト副作用を作成
    * 副作用の作成用コードの実行

詳細については、ワーキンググループの投稿 Adding Reusable State to StrictMode と How to support Reusable State in Effects を参照してください。

テスト環境の設定

まずテストで createRoot を使うようにアップデートした場合、テストコンソールに以下の警告が表示されます：

The current testing environment is not configured to support act(…)

これを修正するには、テスト実行前に globalThis.IS_REACT_ACT_ENVIRONMENT を true に設定します：

// In your test setup file
globalThis.IS_REACT_ACT_ENVIRONMENT = true;

このフラグの目的は、React がユニットテスト的な環境で実行されている、と React に伝えることです。React は更新を act でラップし忘れた場合に、有用な警告を表示するようになります。

このフラグを false に設定することで act が必要ないと React に伝えることもできます。これはフル機能のブラウザ環境をシミュレートする end-to-end テストにおいて有用です。

将来的には、テストライブラリがこれを自動で設定するようになることを期待しています。例えば React Testing Library の次期バージョンは React 18 の組み込みサポートを有しており、追加の設定が不要となっています。

ワーキングループでテスト用 act API および関連する変更に関しての背景が閲覧可能です。

Internet Explorer のサポート終了

このリリースで、React は 2022 年 6 月 15 日にサポート外 となる Internet Explorer のサポートを終了します。この変更を今行うのは、React 18 で導入される新機能はマイクロタスクのようなモダンなブラウザの機能を使っており、IE でうまくポリフィルできないからです。

Internet Explorer のサポートが必要な場合は、React 17 を使い続けることをお勧めします。

非推奨化

• react-dom: ReactDOM.render は非推奨となりました。使うと警告が表示され、アプリは React 17 モードで動作します。
• react-dom: ReactDOM.hydrate は非推奨となりました。使うと警告が表示され、アプリは React 17 モードで動作します。
• react-dom: ReactDOM.unmountComponentAtNode は非推奨となりました。
• react-dom: ReactDOM.renderSubtreeIntoContainer は非推奨となりました。
• react-dom/server: ReactDOMServer.renderToNodeStream は非推奨となりました。

その他の破壊的変更

• useEffect のタイミング統一：React はクリックやキー押下のような個別のユーザ入力によって更新がトリガされた場合に副作用関数を常に同期的に処理するようになりました。これまで、この挙動は必ずしも予測可能な一貫したものではありませんでした。
• ハイドレーション時のエラーの厳格化：テキストコンテンツが存在しない、あるいは余分に存在することによるハイドレーションのミスマッチは、警告ではなくエラーとして扱われるようになりました。今後 React はサーバのマークアップに適合させるために個別のノードをクライアント側で挿入したり削除したりといった「応急処置」を試みないようになるため、ツリー内の直近の <Suspense> バウンダリまでクライアント側のレンダーを使うための逆戻りが発生してしまいます。この変更により、ハイドレーションされたツリーに一貫性があることが保証され、ハイドレーション時のミスマッチにより起こりうる個人情報やセキュリティ絡みの問題を防止できます。
• サスペンス内のツリーが常に一貫性のあるものに：コンポーネントがツリーに完全に追加される前にサスペンドした場合、React はそれを不完全な状態のままツリーに追加したり、副作用を起動したりはしません。その代わり、React は新しいツリーを完全に破棄し、非同期の操作が完了するのを待ち、最初からレンダーを再試行します。React は再試行を、並行的に、ブラウザをブロックせずに行います。
• サスペンスとレイアウト副作用：ツリーが再サスペンドしてフォールバックに逆戻りする場合、React はレイアウト用の副作用をクリーンアップし、バウンダリ内のコンテンツが再表示されるときにそれらを再作成するようになりました。これにより、サスペンスと一緒に使用されたときにコンポーネントライブラリがレイアウトを正しく測定できないという問題が修正されます。
• JS 環境の要件変更：React は Promise、Symbol、Object.assign のようなモダンブラウザの機能に依存するようになりました。モダンなブラウザ機能についてネイティブ実装していないか非標準な実装をしている Internet Explorer のような古いブラウザやデバイスをサポートする場合は、バンドルされたアプリにグローバルなポリフィルを含めることを検討してください。

その他の注目すべき変更

React

• コンポーネントが undefined を return できるように：React はコンポーネントから undefined が返された場合でも警告しなくなりました。これにより、コンポーネントからの返り値として許される値が、コンポーネントツリーの中間で許可される値と合致するようになりました。JSX の前に return 文を書き忘れるといったミスを防ぐためには、リンタを使用することをお勧めします。
• テストにおいて act 警告がオプトインに：End-to-end のテストを実行している場合、act 警告は不要です。オプトインするメカニズムを用意しましたので、それが有用であるユニットテストの場合にのみ有効化できるようになりました。
• アンマウント済みコンポーネントにおける setState で警告を表示しないように：これまで React は、setState がアンマウント済みのコンポーネントでコールされた場合、メモリリークに関する警告を表示してきました。この警告は購読に関する問題のために存在していましたが、state をセットしても問題ないシナリオでもこの警告にぶつかることが多く、また回避しようとした場合余計に悪いコードになってしまっていました。この警告は削除されました。
• コンソールログの抑止を廃止：strict モードを利用する場合、React はコンポーネントを 2 回レンダーして、予期しない副作用がないか見つけやすくします。React 17 では、ログが見やすくなるようにそのうちの 1 回ではコンソールログを抑止するようにしていました。これが混乱を招くというコミュニティからのフィードバックを受けて、このような抑止を行うことを止めました。代わりに、React DevTools をインストールしている場合は、2 回目のレンダーでのログはグレーで表示されるようになりました。完全に抑止するためのオプション（デフォルトではオフ）も存在します。
• メモリ使用量の改善：React はアンマウント時に内部のフィールドをより多く消去するようになったため、あなたのアプリに未修正のメモリリークがあった場合の悪影響が軽減されます。

React DOM Server

• renderToString：サーバ側でサスペンドが起きた場合でもエラーにならなくなりました。代わりに、直近の <Suspense> にあるフォールバック HTML を出力し、クライアント側で同じコンテンツのレンダーを再試行するようになります。とはいえ、renderToPipeableStream や renderToReadableStream のようなストリーミング API に切り替えることが推奨されます。
• renderToStaticMarkup：サーバ側でサスペンドが起きた場合でもエラーにならなくなりました。代わりに、直近の <Suspense> にあるフォールバック HTML を出力します。

Changelog

変更履歴の全リストはこちらを参照してください。

このブログはアーカイブされています。最新の記事は ja.react.dev/blog でご覧ください。

先週、第 6 回の React Conf を開催しました。これまでの年度において、我々は React Conf のステージ上で、React Native や React Hooks といった業界を変えるような発表をお届けしてきました。本年度は、React 18 のリリースと並行レンダリング機能の段階的な採用から始まる我々のマルチプラットフォーム戦略についての話題を共有しました。

React Conf がオンラインで開催されたのは今回が初めてですが、イベントは 8 つの言語に翻訳され、無料でストリーミング配信されました。世界中の参加者が、カンファレンスの Discord や、すべてのタイムゾーンの方がアクセスしやすいように行われたリプレイイベントに参加しました。登録者数は 50,000 人以上に達し、19 の演題は 60,000 回以上閲覧され、両イベントを通じて Discord には 5,000 人の参加者が集まりました。

すべての発表はオンラインストリーミングで閲覧可能です。

以下が、ステージ上で共有された内容のおさらいとなります。

React 18 と並行レンダリング機能

キーノートでは、React 18 から始まる React の将来のビジョンについて共有しました。

React 18 には、長らく待望されてきた並行レンダラと、サスペンスへの機能追加が、大きな破壊的変更なしに入ります。アプリは、他のメジャーリリースのときと変わらない程度の労力で React 18 にアップグレードして、並行レンダリングの機能を段階的に採用していくことが可能です。

これはつまり、並行モードというものがなくなった、ということです。並列レンダリング機能のみが存在します。

キーノートではさらに、サスペンス、サーバコンポーネント、新たな React ワーキンググループ、そして React Native の長期的な多プラットフォーム戦略についてお話ししました。

Andrew Clark、Juan Tejada、Lauren Tan、Rick Hanlon によるキーノートの全編は以下でご覧ください：

アプリ開発者にとっての React 18

キーノートでは、React 18 RC が評価のために今すぐ利用可能であることを発表しました。さらなるフィードバックを待ちつつも、これが来年初頭に我々が安定版として公開する予定の React のバージョンそのものとなります。

React 18 RC を試すには、dependencies をアップグレードしてください：

npm install react@rc react-dom@rc

そして新しい createRoot API を使うように切り替えます：

// before
const container = document.getElementById('root');
ReactDOM.render(<App />, container);

// after
const container = document.getElementById('root');
const root = ReactDOM.createRoot(container);
root.render(<App/>);

React 18 へのアップグレードのデモについては、Shruti Kapoor による以下の発表をご覧ください：

サスペンスを使ったストリーミングサーバレンダリング

React 18 にはサスペンスを使ったサーバサイドレンダリングのパフォーマンス改善が含まれています。

ストリーミングサーバレンダリングによって、サーバ側で React コンポーネントから HTML を作成し、それをユーザにストリームで送ることができます。React 18 では、Suspense を使ってアプリを小さな単位に分割し、それぞれがアプリの他の部分をブロックせずに独立してストリーミング処理できるようになります。これによりユーザはより早くコンテンツを見ることができ、素早くインタラクションができるようになる、ということです。

詳しくは、Shaundai Person による以下の発表をご覧ください：

React ワーキンググループの立ち上げ

React 18 では、エキスパートや開発者、ライブラリメンテナ、教育者のグループと協力して作業するため、初めてワーキンググループを立ち上げました。彼らとともに、段階的な採用戦略を作成し、useId、useSyncExternalStore, useInsertionEffect といった API の改善を行ってきました。

この試みの概要については、Aakansha’ Doshi による発表をご覧ください：

React の開発者向けツーリング

このリリースにおける新機能をサポートするため、新たに構成された React DevTools チームと、開発者が React アプリをデバッグしやすくするための新たなタイムラインプロファイラについて発表しました。

新たな DevTools の機能についての詳細およびデモについては、Brian Vaughn による発表をご覧ください：

memo 不要の React

より将来に目を向けた話として、Xuan Huang (黄玄) は、React Labs が行っている自動メモ化コンパイラに関する研究の現状についてお話ししました。この発表とコンパイラのプロタイプについての詳細・デモは以下でご覧ください：

React ドキュメントキーノート

React の学習や React による設計についての一連の発表は Rachel Nabors からスタートしました。その中では React の 新ドキュメント に対する我々の注力についてのキーノートがありました：

さらに…

React の学習や React における設計についての以下のような発表がありました：

• Debbie O’Brien: Things I learnt from the new React docs.
• Sarah Rainsberger: Learning in the Browser.
• Linton Ye: The ROI of Designing with React.
• Delba de Oliveira: Interactive playgrounds with React.

Relay、React Native、PyTorch チームからの発表：

• Robert Balicki: Re-introducing Relay.
• Eric Rozell and Steven Moyes: React Native Desktop.
• Roman Rädle: On-device Machine Learning for React Native

アクセシビリティ、ツーリング、サーバコンポーネントについてコミュニティからの発表：

• Daishi Kato: React 18 for External Store Libraries.
• Diego Haz: Building Accessible Components in React 18.
• Tafu Nakazaki: Accessible Japanese Form Components with React.
• Lyle Troxell: UI tools for artists.
• Helen Lin: Hydrogen + React 18.

謝辞

我々自身でカンファレンスを計画したのは今年が初めてでした。多くの方に感謝したいと思います。

まずは発表者の方々に感謝します。Aakansha Doshi、Andrew Clark、Brian Vaughn、Daishi Kato、Debbie O’Brien、Delba de Oliveira、Diego Haz、Eric Rozell、Helen Lin、Juan Tejada、Lauren Tan、Linton Ye、Lyle Troxell、Rachel Nabors、Rick Hanlon、Robert Balicki、Roman Rädle、Sarah Rainsberger、Shaundai Person、Shruti Kapoor、Steven Moyes、Tafu Nakazaki、Xuan Huang (黄玄)。

発表についてのフィードバックを頂いた方々に感謝します。Andrew Clark、Dan Abramov、Dave McCabe、Eli White、Joe Savona、Lauren Tan、Rachel Nabors、Tim Yung。

カンファレンス Discord のセットアップを行い Discord 管理者になっていただいた Lauren Tan に感謝します。

全体の方向性や、多様性とその受け入れについて助言をいただいた Seth Webster に感謝します。

モデレーション関係業務の先頭に立っていただいた Rachel Nabors、そしてモデレーションガイドを作成し、モデレーションチームを率い、翻訳者とモデレータの教育を行い、両イベントのモデレーションに協力していただいた Aisha Blake に感謝します。

モデレータの方々に感謝します。Jesslyn Tannady、Suzie Grange、Becca Bailey、Luna Wei、Joe Previte、Nicola Corti、Gijs Weterings、Claudio Procida、Julia Neumann、Mengdi Chen、Jean Zhang、Ricky Li、Xuan Huang (黄玄).

リプレイイベントのモデレーションやコミュニティへの活動に協力頂いた、React India の Manjula Dube、Sahil Mhapsekar、Vihang Patel、および React China の Jasmine Xie、QiChang Li、YanLun Li に感謝します。

カンファレンスのウェブサイトを構築するのに使った Virtual Event Starter Kit を公開していただいた Vercel、そして Next.js Conf での経験を共有していただいた Lee Robinson と Delba de Oliveira に感謝します。

カンファレンス運営の経験や RustConf 運営からの教訓を共有していただいた Leah Silber に感謝します。彼女の書籍 Event Driven とそこに含まれたカンファレンス運営に関する助言に感謝します。

Women of React Conf の運営経験について共有していただいた Kevin Lewis と Rachel Nabors に感謝します。

企画全体にわたってアドバイスやアイディアをいただいた Aakansha Doshi、Laurie Barth、Michael Chan、Shaundai Person に感謝します。

カンファレンスウェブサイトとチケットのデザイン・構築に協力いただいた Dan Lebowitz に感謝します。

キーノートや Meta 従業員の発表の録画をしていただいた Laura Podolak Waddell、Desmond Osei-Acheampong、Mark Rossi、Josh Toberman および Facebook Video Productions の他の方々に感謝します。

カンファレンスの運営、ストリームされる全ビデオの編集、全発表の翻訳、そして多言語での Discord のモデレーションについて協力いただいたパートナーの HitPlay に感謝します。

最後に、この React Conf を素晴らしいものにしていただいたすべての参加者の皆さんに感謝します！

このブログはアーカイブされています。最新の記事は ja.react.dev/blog でご覧ください。

2021 年 11 月 15 日追記：

React 18 はベータ版となりました。リリースに関する最新情報は React 18 ワーキンググループの投稿で確認できます。

React チームより幾つかのお知らせがあります！

1. 次のメジャーバージョンとなる React 18 リリースに向けての作業を開始しました。
2. コミュニティが React 18 の新機能を段階的に導入できるようにするため、ワーキンググループを作成しました。
3. ライブラリの作者が試用してフィードバックを送れるようにするため、React 18 のアルファ版を公開しました。

これらのお知らせは、主にサードパーティのライブラリメンテナ向けです。ユーザ向けのアプリケーションを作成するために React を学んでいる、教えている、あるいは利用している方は、この投稿を無視していただいて問題ありません。もちろん興味があれば React 18 ワーキンググループでの議論をフォローすることは歓迎です！

React 18 の新機能

React 18 のリリース時点で、自動で有効になるパフォーマンス改善（例：自動バッチング）、新たな API（例：startTransition）、そして React.lazy の組み込みサポートを有する新しいストリーミングサーバレンダラが含まれています。

これらは、React 18 で我々が追加しようとしている新たなオプトインのメカニズムのおかげで実現可能になるものです。そのメカニズムとは「並行レンダリング」であり、これにより React は、UI の複数のバージョンを同時に用意しておくことができるようになります。これはほとんどの場面では裏で勝手に行われますが、あなたのアプリの実パフォーマンスおよび体感上のパフォーマンスを向上させる可能性を秘めています。

我々が React の未来に向けて行ってきた様々なリサーチをフォローしてきた方であれば（そうすべきと言っている訳ではないですよ）、“Concurrent Mode” なる言葉を聞いたこと、あるいはそれのせいであなたのアプリが動かなくなるかもしれないということを聞いたことがあるかもしれません。これに関してのコミュニティのフィードバックを受けて、我々は段階的な導入に向けてのアップグレード戦略を再設計しました。イチかゼロかの「モード」の代わりに、並行レンダリングは新機能のどれかを利用するような更新がある場合にのみ有効化されるようになりました。実用上、これはつまり書き換えをせずに React 18 を導入し、自分のペースで React 18 の新機能を試していけるようになるということです。

段階的な導入戦略

React 18 における並行レンダリングはオプトインになるため、コンポーネントの振る舞いにおいてデフォルトで大きな破壊的変更があるということはなくなります。いつものメジャーリリースのときに要する労力と大差ないレベルの最小限の書き換えで、あるいは書き換えゼロで、React 18 にアップグレードすることができます。我々がいくつかのアプリを React 18 に移植した経験から、多くのユーザは半日以内にアップグレード作業を完了できるだろうと考えています。

Facebook 内では既に数万のコンポーネントを並行レンダリングの機能を用いてリリースすることができました。我々の経験ではほとんどの React コンポーネントは追加の開発なしで「ごく普通に」動作することが分かっています。しかしコミュニティ全体で今回のアップグレードが確実にスムースに行くようにしたいと考えており、そのために本日、React 18 ワーキンググループを発表します。

コミュニティとの共同作業

このリリースで、私たちは新たな試みをしようとしています。React コミュニティ全体から、少数のエキスパート、開発者、ライブラリ作者、教育関係者を React 18 ワーキンググループに招待して、フィードバックをもらったり、質問をもらったり、リリースに向けての共同作業を行ってもらったりしているのです。初期は小さなグループであり、メンバーとして我々が望む全員を招待することはできませんでしたが、この試みがうまくいけば、将来的により多くの人を招待できると考えています！

React 18 ワーキンググループの目的は、既存のアプリケーションやライブラリが React 18 をスムースかつ段階的に採用できるように、エコシステムを整えることです。ワーキングループは GitHub Discussions でホストされており、誰でも読めるようになっています。ワーキンググループのメンバーのみがフィードバックを送ったり、質問したり、アイディアを共有したりできるようになっています。このディスカッション用のリポジトリは、コアチームのメンバーも研究の成果を共有するために使用します。安定リリースが近づけば、あらゆる重要な情報はこのブログにも投稿されます。

React 18 へのアップグレードに関する詳細やリリースに関するその他の情報については、React 18 アナウンスをご覧ください。

ワーキンググループへのアクセス方法

React 18 ワーキンググループのリポジトリでのディスカッションは、誰でも閲覧可能です。

当初はワーキンググループ内部で一気に興味が高まることが予想されますので、招待されたメンバーのみがスレッドを作成したりコメントしたりできるようになっています。しかしスレッドは誰でも見えるようになっていますので、全員が同じ情報にアクセスできます。ワーキンググループのメンバーにとって生産的な環境を整えつつ、より広いコミュニティへの透明性も確保するという意味で、これが良い落とし所だと考えています。

もちろんこれまで通り、バグレポートや質問や一般的なフィードバックについては誰でもイシュートラッカに投稿することができます。

React 18 アルファ版を今すぐ試す

新しいアルファ版は npm に @alpha タグ付きで定期的に公開されます。これらのリリースは我々のメインリポジトリにある最新のコミットを使ってビルドされます。新しい機能やバグ修正がマージされた場合、次の平日にはアルファ版で利用可能になります。

アルファ版同士の間では動作や API について大きな変更が加わる可能性があります。ユーザが利用する本番用アプリケーションではアルファ版は推奨されないということを銘記してください。

React 18 リリースタイミングの見通し

具体的に予定されたリリース日時はまだありませんが、React 18 が本番アプリケーションで使えるようになるまでに、フィードバックを受けて改善を繰り返す期間が数か月ほど必要だろうと考えています。

• ライブラリ作者向けのアルファ：本日より利用可能
• 公開ベータ：少なくとも数か月後
• リリース候補 (RC)：ベータから少なくとも数週間後
• 一般向けリリース：RC から少なくとも数週間後

リリースタイミングの見通しについての更なる詳細はワーキンググループ内の投稿で見ることができます。公開リリースが近づいたらこのブログでも情報をお伝えします。

このブログはアーカイブされています。最新の記事は ja.react.dev/blog でご覧ください。

2020 年は長い 1 年でした。本年の最後に、我々の研究における特別なホリデーアップデートとして、バンドルサイズゼロで動作する React サーバコンポーネントの紹介をしたいと思います。

サーバコンポーネントの紹介のためのトークとデモを用意しました。休暇期間中にチェックするもよし、来年仕事に戻ってきた時に見てみるのでもよいでしょう。

React サーバコンポーネントは現在も研究開発中です。開発の透明性を高め、React コミュニティから初期のフィードバックを頂くために共有しています。そのための時間はまだまだありますので、今すぐ追いつく必要はありません！

もし気になったなら以下の順番で見ていくのをお勧めします。

1. トークを見て React サーバコンポーネントについて学び、デモを見る
2. デモをクローンして自分のコンピュータ上で React サーバコンポーネントで遊んでみる
3. 技術的に深い部分について RFC を読み（FAQ も最後にあります）、フィードバックを送る

RFC や Twitter の @reactjs へのリプライで、皆さんの意見を聞けるのを楽しみにしています。それでは良い休暇を！ また来年お元気でお会いしましょう！

このブログはアーカイブされています。最新の記事は ja.react.dev/blog でご覧ください。

本日、React 17 をリリースします！ React 17 リリースの役割や含まれている変更点については React 17 RC のブログ記事で詳しく述べてあります。この記事はそちらの短いサマリとなりますので、RC の記事を既に読んでいる場合は、本記事は飛ばして構いません。

新機能 “なし”

この React 17 リリースは普段のリリースと異なっており、開発者向けの新機能が何も追加されていません。代わりに、このリリースは React 自体のアップグレードを簡単にすることに焦点を当てています。

具体的には React 17 は、あるバージョンの React で管理されるツリー内に、別のバージョンの React で管理されるツリーをより安全に埋め込めるようにするための、「踏み台」となるリリースとなっています。

また、他のテクノロジによって構築されているアプリ内に React を埋め込むことも容易になります。

段階的なアップグレード

React 17 は段階的な React のアップグレードを可能にします。React 15 から 16 に（そして今回は React 16 から 17 に）アップグレードする場合、普通はアプリ全体をまとめてアップグレードします。これは多くのアプリではうまく行きます。しかしコードが数年以上前に書かれており活発にメンテされていないような場合、だんだんと難易度が増していきます。ページ内で 2 つの React のバージョンを混在させることは可能ですが、React 17 以前にこのようなことをすると不安定になり、イベント絡みの問題が引き起こされていました。

React 17 で、これらの問題の多くを修正します。これは React 18 やもっと将来のバージョンが来たときに、とれる選択肢が増えるということを意味します。選択肢のひとつは、これまでやってきたのと同様、アプリ全体を一度にアップグレードするというものです。しかし今後は、アプリを一部分ずつアップグレードするという選択肢がとれるようになります。例えば、アプリの大部分を React 18 に移行しつつ、いくつかの遅延ロードされるダイアログやサブページを React 17 のままにしておけるようになります。

だからといって段階的に更新しないといけないという訳ではありません。今後もほとんどのアプリでは、一気にアップグレードするのがベストの選択肢です。2 つのバージョンの React をロードするというのは、たとえ片方はオンデマンドで遅延ロードするのだとしても、やはり理想的ではありません。しかし、活発にメンテされていない大きなアプリではこの選択肢は検討に値するものであり、React 17 はこのようなアプリが取り残されずに済むようにします。

古いバージョンの React を必要に応じて遅延ロードするという手法をデモするためのサンプルリポジトリを用意しました。このデモは Create React App を使っていますが、他のどのようなツールでも似たアプローチが可能なはずです。他のツールを使ったデモを追加するプルリクエストを歓迎します。

補足

その他の変更は React 17 より後に延期しました。このリリースの目標は段階的なアップグレードを可能にすることです。React 17 自体へのアップグレードが難しいようでは本リリースの目的が台無しですので、そのようなことはないはずです。

イベントデリゲーションに関する変更

段階的なアップグレードを可能にするために、React のイベントシステムに幾つかの変更を加える必要がありました。React 17 がメジャーリリースとなっているのは、これらの変更が一部互換性の問題を引き起こす可能性があるからです。我々の安定性に対する取り組みについてはバージョニングについての FAQ で読むことができます。

React 17 では、React は裏で document のレベルにイベントハンドラをアタッチしないようになります。代わりに、あなたが React ツリーをレンダーしようとしているルート DOM コンテナに対してアタッチするようになります：

const rootNode = document.getElementById('root');
ReactDOM.render(<App />, rootNode);

React 16 およびそれ以前では、React はほとんどのイベントに対して document.addEventListener() のようにしていました。代わりに React 17 は、水面下で rootNode.addEventListener() という呼び出しを行うようになります。

この新しい挙動により、React コードと非 React コードの統合に関して 過去 数年に わたって 報告 されて きた 様々な 問題が 解決 される ことが分かっています。

この変更により問題が出た場合は、こちらによくある解決法が載っています。

その他の破壊的変更

React 17 RC のブログ記事 に React 17 におけるその他の破壊的変更について説明があります。

Facebook のプロダクトコードにおける 10 万を超えるのコンポーネントのうち、これらの変更に対応するために変更する必要があったのは 20 未満でしたので、ほとんどのアプリは React 17 にトラブルなく移行できると考えています。問題があった場合は知らせてください。

新しい JSX トランスフォーム

Raect 17 は新しい JSX トランスフォームをサポートします。このサポートは React 16.14.0、React 15.7.0、React 0.14.10 にもバックポートされています。これは完全にオプトインであり、使う必要はないということに留意してください。以前の JSX トランスフォームも動作し続けますし、サポートを終了する予定はありません。

React Native

React Native のリリーススケジュールは React と異なっています。React 17 へのサポートは React Native 0.64 にて追加されました。いつものように、リリースに関する議論は React Native Community のリリースに関するイシュートラッカで追うことができます。

インストール

React 17 を npm でインストールするには以下のようにします：

npm install react@17.0.0 react-dom@17.0.0

React 17 を Yarn でインストールするには以下のようにします：

yarn add react@17.0.0 react-dom@17.0.0

CDN 経由で React の UMD ビルドも提供しています：

<script crossorigin src="https://unpkg.com/react@17.0.0/umd/react.production.min.js"></script>
<script crossorigin src="https://unpkg.com/react-dom@17.0.0/umd/react-dom.production.min.js"></script>

詳細なインストール手順についてはドキュメントを参照してください。

Changelog

React

• Add react/jsx-runtime and react/jsx-dev-runtime for the new JSX transform. (@lunaruan in #18299)
• Build component stacks from native error frames. (@sebmarkbage in #18561)
• Allow to specify displayName on context for improved stacks. (@eps1lon in #18224)
• Prevent 'use strict' from leaking in the UMD bundles. (@koba04 in #19614)
• Stop using fb.me for redirects. (@cylim in #19598)

React DOM

• Delegate events to roots instead of document. (@trueadm in #18195 and others)
• Clean up all effects before running any next effects. (@bvaughn in #17947)
• Run useEffect cleanup functions asynchronously. (@bvaughn in #17925)
• Use browser focusin and focusout for onFocus and onBlur. (@trueadm in #19186)
• Make all Capture events use the browser capture phase. (@trueadm in #19221)
• Don’t emulate bubbling of the onScroll event. (@gaearon in #19464)
• Throw if forwardRef or memo component returns undefined. (@gaearon in #19550)
• Remove event pooling. (@trueadm in #18969)
• Stop exposing internals that won’t be needed by React Native Web. (@necolas in #18483)
• Attach all known event listeners when the root mounts. (@gaearon in #19659)
• Disable console in the second render pass of DEV mode double render. (@sebmarkbage in #18547)
• Deprecate the undocumented and misleading ReactTestUtils.SimulateNative API. (@gaearon in #13407)
• Rename private field names used in the internals. (@gaearon in #18377)
• Don’t call User Timing API in development. (@gaearon in #18417)
• Disable console during the repeated render in Strict Mode. (@sebmarkbage in #18547)
• In Strict Mode, double-render components without Hooks too. (@eps1lon in #18430)
• Allow calling ReactDOM.flushSync during lifecycle methods (but warn). (@sebmarkbage in #18759)
• Add the code property to the keyboard event objects. (@bl00mber in #18287)
• Add the disableRemotePlayback property for video elements. (@tombrowndev in #18619)
• Add the enterKeyHint property for input elements. (@eps1lon in #18634)
• Warn when no value is provided to <Context.Provider>. (@charlie1404 in #19054)
• Warn when memo or forwardRef components return undefined. (@bvaughn in #19550)
• Improve the error message for invalid updates. (@JoviDeCroock in #18316)
• Exclude forwardRef and memo from stack frames. (@sebmarkbage in #18559)
• Improve the error message when switching between controlled and uncontrolled inputs. (@vcarl in #17070)
• Keep onTouchStart, onTouchMove, and onWheel passive. (@gaearon in #19654)
• Fix setState hanging in development inside a closed iframe. (@gaearon in #19220)
• Fix rendering bailout for lazy components with defaultProps. (@jddxf in #18539)
• Fix a false positive warning when dangerouslySetInnerHTML is undefined. (@eps1lon in #18676)
• Fix Test Utils with non-standard require implementation. (@just-boris in #18632)
• Fix onBeforeInput reporting an incorrect event.type. (@eps1lon in #19561)
• Fix event.relatedTarget reported as undefined in Firefox. (@claytercek in #19607)
• Fix “unspecified error” in IE11. (@hemakshis in #19664)
• Fix rendering into a shadow root. (@Jack-Works in #15894)
• Fix movementX/Y polyfill with capture events. (@gaearon in #19672)
• Use delegation for onSubmit and onReset events. (@gaearon in #19333)
• Improve memory usage. (@trueadm in #18970)

React DOM Server

• Make useCallback behavior consistent with useMemo for the server renderer. (@alexmckenley in #18783)
• Fix state leaking when a function component throws. (@pmaccart in #19212)

React Test Renderer

• Improve findByType error message. (@henryqdineen in #17439)

Concurrent Mode (Experimental)

• Revamp the priority batching heuristics. (@acdlite in #18796)
• Add the unstable_ prefix before the experimental APIs. (@acdlite in #18825)
• Remove unstable_discreteUpdates and unstable_flushDiscreteUpdates. (@trueadm in #18825)
• Remove the timeoutMs argument. (@acdlite in #19703)
• Disable <div hidden /> prerendering in favor of a different future API. (@acdlite in #18917)
• Add unstable_expectedLoadTime to Suspense for CPU-bound trees. (@acdlite in #19936)
• Add an experimental unstable_useOpaqueIdentifier Hook. (@lunaruan in #17322)
• Add an experimental unstable_startTransition API. (@rickhanlonii in #19696)
• Using act in the test renderer no longer flushes Suspense fallbacks. (@acdlite in #18596)
• Use global render timeout for CPU Suspense. (@sebmarkbage in #19643)
• Clear the existing root content before mounting. (@bvaughn in #18730)
• Fix a bug with error boundaries. (@acdlite in #18265)
• Fix a bug causing dropped updates in a suspended tree. (@acdlite in #18384 and #18457)
• Fix a bug causing dropped render phase updates. (@acdlite in #18537)
• Fix a bug in SuspenseList. (@sebmarkbage in #18412)
• Fix a bug causing Suspense fallback to show too early. (@acdlite in #18411)
• Fix a bug with class components inside SuspenseList. (@sebmarkbage in #18448)
• Fix a bug with inputs that may cause updates to be dropped. (@jddxf in #18515 and @acdlite in #18535)
• Fix a bug causing Suspense fallback to get stuck. (@acdlite in #18663)
• Don’t cut off the tail of a SuspenseList if hydrating. (@sebmarkbage in #18854)
• Fix a bug in useMutableSource that may happen when getSnapshot changes. (@bvaughn in #18297)
• Fix a tearing bug in useMutableSource. (@bvaughn in #18912)
• Warn if calling setState outside of render but before commit. (@sebmarkbage in #18838)

このブログはアーカイブされています。最新の記事は ja.react.dev/blog でご覧ください。

React 17 には新機能はありませんが、新バージョンの JSX トランスフォーム (JSX transform) に対応します。この記事ではこれがどのようなもので、どのように試せるのかについて説明します。

JSX トランスフォームとは？

ブラウザはそのままでは JSX を理解しないため、ほとんどの React ユーザは、Babel や TypeScript のようなコンパイラを利用して JSX コードを通常の JavaScript に変換 (transform) しています。Create React App や Next.js のような多くの設定済みツールキットも、裏では JSX トランスフォーム機能を搭載しています。

React 17 のリリースとともに、JSX トランスフォームにいくつかの改良を加えたいと思っていましたが、既存のセットアップを壊したくもありませんでした。そのため、Babel と協力して、アップグレードしたい人のために JSX トランスフォームの新バージョンを提供することにしました。

新しいトランスフォームへのアップグレードは完全に任意ですが、いくつかの利点があります。

• 新版のトランスフォームでは、React をインポートせず JSX を使用できます。
• セットアップによっては、コンパイル後のバンドルサイズをわずかに改善できる可能性があります。
• 将来的に、React を学ぶために覚える必要がある概念の数を減らすような改善が可能になります。

このアップグレードは JSX の構文を変更するものではなく、必須でもありません。以前の JSX トランスフォームもこれまで通り動作し続けますし、それらのサポートを削除する予定もありません。

React 17 RC にはすでに新しいトランスフォームのサポートが含まれていますので、試してみてください。より簡単に導入できるよう、React 16.14.0、React 15.7.0、React 0.14.10 へのバックポートも行っています。記事の後半で様々なツールにおけるアップグレード方法を記載しています。

では、新旧のトランスフォームの違いを詳しく見ていきましょう。

新しいトランスフォームは何が違うのか？

JSX を使うと、コンパイラはそれをブラウザが理解できる React の関数呼び出しに変換します。以前の JSX トランスフォーム機能では、JSX を React.createElement(...) 呼び出しに変換していました。

例えば、ソースコードが以下のようになっているとします。

import React from 'react';

function App() {
  return <h1>Hello World</h1>;
}

裏側では、以前の JSX トランスフォームはこれを以下のような通常の JavaScript に変換します。

import React from 'react';

function App() {
  return React.createElement('h1', null, 'Hello world');
}

補足

あなたのソースコードをこう変えろという話ではありません。これは、JSX トランスフォームがあなたの JSX ソースコードをブラウザが理解できるコードへとどのように変換するのかを説明しているものです。

しかし、これで完璧とは言えません。

• JSX が React.createElement へとコンパイルされるため、JSX を使用する場合は React をスコープに入れる必要がありました。
• React.createElement では行えないパフォーマンス向上と単純化方法がいくつか存在します。

これらの問題を解決するために、React 17 では React パッケージに、Babel や TypeScript のようなコンパイラのみが使用することを意図した 2 つの新しいエントリポイントを導入しています。JSX を React.createElement に変換する代わりに、新しい JSX トランスフォームは、React パッケージのこれらの新しいエントリポイントから特別な関数を自動的にインポートし、それらを呼び出します。

ソースコードが以下のようになっているとしましょう。

function App() {
  return <h1>Hello World</h1>;
}

新しい JSX トランスフォームは、これをこのようなコードにコンパイルします。

// Inserted by a compiler (don't import it yourself!)
import {jsx as _jsx} from 'react/jsx-runtime';

function App() {
  return _jsx('h1', { children: 'Hello world' });
}

JSX を使用するために React をインポートする必要がなくなっていることに注意してください！（ただし、React が提供するフックやその他のエクスポートを使用するためには、引き続き React をインポートする必要があります）。

この変更は、既存のあらゆる JSX コードと完全に互換性がありますので、あなたのコンポーネントを変更する必要はありません。興味がある方は、新しいトランスフォームがどのように動作するかの詳細についてテクニカル RFC をチェックしてみてください。

補足

react/jsx-runtime と react/jsx-dev-runtime 内の関数は、コンパイラによるトランスフォーム機能によってのみ使用されなければなりません。コードの中で手動で要素を作成する必要がある場合は、React.createElement を使い続けるべきです。これは動作し続けますし、なくなることはありません。

新しい JSX トランスフォームへのアップグレード

新しい JSX トランスフォームにアップグレードする準備ができていない場合や、別のライブラリで JSX を使用している場合でも、心配は要りません。古いトランスフォームは削除されず、引き続きサポートされます。

アップグレードしたい場合は、以下の 2 つのものが必要です。

• 新しいトランスフォームをサポートする React のバージョン（React 17 RC 以降でサポートされますが、以前のメジャーバージョンに留まりたい方のために React 16.10.0、React 15.7.0、React 0.14.10 もリリースしてあります）。
• 互換性のあるコンパイラ（下記のツールごとの説明を参照）。

新しい JSX 変換は React をスコープに入れる必要がないので、コードベースから不要なインポートを削除する自動化スクリプトも用意しました。

Create React App

Create React App 4.0.0 以降で互換性のある React のバージョンに対して新しいトランスフォームを利用します。

Next.js

Next.js v9.5.3 以降、互換性のある React のバージョンに対して新しいトランスフォームを利用します。

Gatsby

Gatsby v2.24.5 以降、互換性のある React のバージョンに対して新しいトランスフォームを使用します。

補足

React 17 RC にアップグレードした後にこの Gatsby エラーが出た場合は、npm update を実行することで修正できます。

Babel の手動セットアップ

新しい JSX トランスフォームのサポートは、Babel v7.9.0 以上で利用可能です。

まず、最新の Babel とトランスフォームプラグインにアップデートする必要があります。

@babel/plugin-transform-react-jsx を利用している場合：

# for npm users
npm update @babel/core @babel/plugin-transform-react-jsx

# for yarn users
yarn upgrade @babel/core @babel/plugin-transform-react-jsx

@babel/preset-react を利用している場合：

# for npm users
npm update @babel/core @babel/preset-react

# for yarn users
yarn upgrade @babel/core @babel/preset-react

現在のところは以前のトランスフォーム {"runtime": "classic"} がデフォルトのオプションです。新しいトランスフォームを有効にするには、@babel/plugin-transform-react-jsx ないし @babel/preset-react のオプションとして {"runtime": "automatic"} を渡してください。

// If you are using @babel/preset-react
{
  "presets": [
    ["@babel/preset-react", {
      "runtime": "automatic"
    }]
  ]
}

// If you're using @babel/plugin-transform-react-jsx
{
  "plugins": [
    ["@babel/plugin-transform-react-jsx", {
      "runtime": "automatic"
    }]
  ]
}

Babel 8 からは、"automatic" が両方のプラグインでデフォルトのランタイムとなります。詳細については、Babel ドキュメントの @babel/plugin-transform-react-jsx と @babel/preset-react を参照してください。

補足

JSX を React 以外のライブラリで使用している場合、そのライブラリが必要なエントリポイントを提供しているのであれば、importSource オプション を使ってそこからインポートするよう指定することができます。あるいは、引き続きサポートされる旧版のトランスフォームを使い続けることもできます。

ライブラリ作者の方で /jsx-runtime エントリポイントをあなたのライブラリに実装しようとしている場合、後方互換性のため新しいトランスフォームが createElement にフォールバックするケースがあることに留意してください。この場合、importSource に指定されたルートエントリポイントから createElement を自動でインポートします。

ESLint

eslint-plugin-react を使用している場合、react/jsx-uses-react と react/react-in-jsx-scope のルールは不要になりますので、無効にするか削除することができます。

{
  // ...
  "rules": {
    // ...
    "react/jsx-uses-react": "off",
    "react/react-in-jsx-scope": "off"
  }
}

TypeScript

TypeScript は新しい JSX トランスフォームを v4.1 以降でサポートします。

Flow

Flow v0.126.0 以降で、設定オプションに react.runtime=automatic を追加することで新しい JSX トランスフォームをサポートします。

未使用 React インポートの削除

新しい JSX トランスフォームは、必要とする react/jsx-runtime 関数を自動的にインポートするため、JSX を使用する際に React をスコープに入れる必要がなくなります。これにより、コードの中で React のインポートが未使用となる可能性があります。残しておいても害はありませんが、削除したい場合は “codemod” スクリプトを実行して自動的に行うことをお勧めします。

cd your_project
npx react-codemod update-react-imports

補足

codemod の実行時にエラーが出る場合は、npx react-codemod update-react-imports で別の JavaScript の方言を指定してみてください。特に、現時点では “JavaScript with Flow” の設定は、“JavaScript” の設定よりも新しい構文をサポートしていますので、Flow を使用していない場合でも試してみてください。問題が発生した場合は issue を報告 してください。

また、codemod の出力はあなたのプロジェクトのコーディングスタイルと必ずしも一致はしませんので、一貫したフォーマットにするため codemod の終了後に Prettier を実行すると良いかもしれません。

この codemod を実行すると以下のことを行います：

• 新しい JSX トランスフォームにアップグレードした結果使用されなくなる React のインポートをすべて削除します。
• すべての React のデフォルトインポート（すなわち、import React from "react"）を、将来的に望ましいスタイルである分割代入型の名前付きインポート（例えば、import { useState } from "react"）に変更します。名前空間インポート（すなわち、import * as React from "react"）も有効な形式であり、codemod はこれらは変換しません。デフォルトインポートは React 17 でも動作し続けますが、長期的にはそれらのインポートを利用しないようにすることを推奨します。

例えば、

import React from 'react';

function App() {
  return <h1>Hello World</h1>;
}

は、以下に置き換わります：

function App() {
  return <h1>Hello World</h1>;
}

他のもの（例えばフック）を React からインポートしている場合は、codemod はそれらを名前付きインポートへと変換します。

例えば、

import React from 'react';

function App() {
  const [text, setText] = React.useState('Hello World');
  return <h1>{text}</h1>;
}

は、以下に置き換わります：

import { useState } from 'react';

function App() {
  const [text, setText] = useState('Hello World');
  return <h1>{text}</h1>;
}

未使用のインポートをクリーンアップすることに加えて、これは ES Modules をサポートしデフォルトエクスポートを持たない将来のメジャーバージョンの React（React 17 のことではありません）への準備にも役立ちます。

謝辞

新しい JSX トランスフォームの実装と統合を手伝っていただいた Babel、TypeScript、Create React App、Next.js、Gatsby、ESLint および Flow のメンテナの方々に感謝します。また、テクニカル RFC においてフィードバックや議論をしていただいた React コミュニティにも感謝します。

このブログはアーカイブされています。最新の記事は ja.react.dev/blog でご覧ください。

本日 React 17 の最初のリリース候補を公開します。前回の React メジャーリリースから 2 年半が経過しており、これは我々の基準からしても長いものです！ このブログ記事では、このメジャーリリースの役割、期待される変化、そしてどのように試すことができるのかについて説明します。

新機能 “なし”

この React 17 リリースは普段のリリースと異なっており、開発者向けの新機能が何も追加されていません。代わりに、このリリースは React 自体のアップグレードを簡単にすることに焦点を当てています。

我々は React の新機能を積極的に開発中ですが、それらの新機能はこのリリースに含まれていません。React 17 のリリースは、誰も取り残されないようにしつつ新機能を展開していくという私たちの戦略の鍵となるものです。

具体的には React 17 は、あるバージョンの React で管理されるツリー内に、別のバージョンの React で管理されるツリーをより安全に埋め込めるようにするための、「踏み台」となるリリースとなっています。

段階的なアップグレード

過去 7 年間、React のアップグレードは “all-or-nothing” 型でした。古いバージョンにとどまり続けるか、新バージョンにアプリ全体をアップグレードするかの二択です。その中間は存在しませんでした。

これまではそれで何とかなっていましたが、我々は “all-or-nothing” なアップグレード戦略の限界に直面しています。例えば、古いコンテクスト API の非推奨化のようないくつかの API 変更への対応は、自動化して行うことができません。最近に書かれたアプリのほとんどはこれを一切使っていないにも関わらず、React はこれをサポートし続けています。ずっとこれをサポートし続けるか、幾つかのアプリを古いバージョンの React のまま取り残すしかしかないのです。どちらの選択肢もあまり望ましくありません。

そこで我々はもうひとつの選択肢を用意することにしました。

React 17 は段階的な React のアップグレードを可能にします。React 15 から 16 に（そして近い将来 React 16 から 17 に）アップグレードする場合、普通はアプリ全体をまとめてアップグレードします。これは多くのアプリではうまく行きます。しかしコードが数年以上前に書かれており活発にメンテされていないような場合、だんだんと難易度が増していきます。ページ内で 2 つの React のバージョンを混在させることは可能ですが、React 17 以前にこのようなことをすると不安定になり、イベント絡みの問題が引き起こされていました。

React 17 で、これらの問題の多くを修正します。これは React 18 やもっと将来のバージョンが来たときに、とれる選択肢が増えるということを意味します。選択肢のひとつは、これまでやってきたのと同様、アプリ全体を一度にアップグレードするというものです。しかし今後は、アプリを一部分ずつアップグレードするという選択肢がとれるようになります。例えば、アプリの大部分を React 18 に移行しつつ、いくつかの遅延ロードされるダイアログやサブページを React 17 のままにしておけるようになります。

だからといって段階的に更新しないといけないという訳ではありません。今後もほとんどのアプリでは、一気にアップグレードするのがベストの選択肢です。2 つのバージョンの React をロードするというのは、たとえ片方はオンデマンドで遅延ロードするのだとしても、やはり理想的ではありません。しかし、活発にメンテされていない大きなアプリではこの選択肢は検討に値するものであり、React 17 はこのようなアプリが取り残されずに済むようにします。

段階的なアップグレードを可能にするために、React のイベントシステムに幾つかの変更を加える必要がありました。React 17 がメジャーリリースとなっているのは、これらの変更が一部互換性の問題を引き起こす可能性があるからです。実際のところは、10 万を超えるコンポーネントの中で変更する必要があったのは 20 未満でしたので、ほとんどのアプリは React 17 にトラブルなく移行できると考えています。問題があった場合は知らせてください。

段階的アップグレードのデモ

古いバージョンの React を必要に応じて遅延ロードするという手法をデモするためのサンプルリポジトリを用意しました。このデモは Create React App を使っていますが、他のどのようなツールでも似たアプローチが可能なはずです。他のツールを使ったデモを追加するプルリクエストを歓迎します。

補足

その他の変更は React 17 より後に延期しました。このリリースの目標は段階的なアップグレードを可能にすることです。React 17 自体へのアップグレードが難しいようでは本リリースの目的が台無しですので、そのようなことはないはずです。

イベントデリゲーションに関する変更

異なるバージョンの React で作成されたアプリをネストさせることは、技術的にはこれまでも可能でしたが、React のイベントシステムの挙動に起因して不安定なものとなっていました。

React コンポーネントでは、通常はイベントハンドラをインラインで記載します：

<button onClick={handleClick}>

このコードは素の DOM では以下と同等です：

myButton.addEventListener('click', handleClick);

しかし、ほとんどのイベントでは、実際には React はあなたが宣言した DOM ノードにイベントハンドラをアタッチするのではありません。代わりに、イベントタイプごとにハンドラを 1 つだけ、document ノードに直接アタッチします。これはイベントデリゲーション（event delegation; イベントの委譲）と呼ばれます。大きなアプリケーションツリーではパフォーマンス面で有利であるということに加え、これによりイベントのリプレイといった新機能も追加しやすくなります。

React は最初のリリース時点からこのようなイベントデリゲーションを自動的に行っていました。ドキュメントで DOM イベントが発生すると、React はどのコンポーネントを呼び出すべきか判定し、React のイベントがあなたのコンポーネントツリー内を上側に向かって「バブリング」していきます。しかしその裏側では、この時点でネイティブのイベントが既に document のレベルにバブリングし終わっているのであり、そこに React はイベントハンドラを仕込んでいるのです。

ところがこの挙動が、段階的なアップグレードにおいて問題を引き起こします。

ページ内に複数の React バージョンがあると、それらがすべてイベントハンドラをトップレベルに登録します。これにより e.stopPropagation() がおかしくなります。例えばネストされている側のツリーがとあるイベントの伝播を停止した場合でも、外側のツリーがそれを受け取ることができてしまいます。これが複数の異なるバージョンの React をネストさせるのが難しかった理由です。この懸念は架空の話ではなく、例えば Atom エディタは 4 年前に実際にこの問題に遭遇しています。

以上が、React が裏で DOM にイベントをアタッチする方法を、我々が変更しようとしている理由です。

React 17 では、React は document レベルにイベントハンドラをアタッチしないようになります。代わりに、あなたが React ツリーをレンダーしようとしているルート DOM コンテナに対してアタッチするようになります。

const rootNode = document.getElementById('root');
ReactDOM.render(<App />, rootNode);

React 16 およびそれ以前では、React はほとんどのイベントに対して document.addEventListener() のようにしていました。代わりに React 17 は、水面下で rootNode.addEventListener() という呼び出しを行うようになります。

この変更のおかげで、あるバージョンの React で管理されているツリーを別バージョンの React で管理されているツリー内に埋め込むことが、より安全に行えるようになります。ただしこれがうまく働くためにはどちらの React のバージョンも 17 以上である必要があり、これが React 17 にアップグレードすることが重要である理由です。ある意味で、React 17 は、今回以降に段階的なアップグレードを行いやすくするための「踏み台」リリースであると言えます。

この変更により、他のテクノロジーで構築されたアプリ内に React を組み込むことも容易になります。例えば、外見の大部分を jQuery で書いており、その中の新しいコードが一部 React で書かれているという場合でも、今後は「React 内で e.stopPropagation() が呼ばれたイベントは jQuery のコードに到達しない」という（期待通りの）動作をするようになります。逆のことも言えます。もし React が好きではなくなってアプリを（例えば jQuery で）書き直したくなったとしても、イベント伝播処理を壊すことなく見た目部分を React から jQuery に移行することができるようになります。

この新しい挙動により、React コードと非 React コードの統合に関して 過去 数年に わたって 報告 されて きた 様々な 問題が 解決 される ことが分かっています。

補足

この変更によりルートコンテナ外にあるポータルの動作がおかしくなるのではと思っているかもしれません。が、React はポータルのコンテナでもイベントをリッスンするようになるため、問題は生じません。

問題が出た場合の修正方法

どのような破壊的変更もそうですが、コードの一部は調整する必要があるかもしれません。Facebook では（何千ものモジュールがあるうち）合計で約 10 個のモジュールを、今回の変更に合わせて調整する必要がありました。

例えば document.addEventListener(...) という形で手動で DOM リスナを登録すれば、それにより React のすべてのイベントが捕捉できると期待するかもしれません。React 16 以前では、React のイベントハンドラ内で e.stopPropagation() をコールしていたとしても、document にあるあなたのカスタムのリスナはこのイベントを受け取っていました。なぜならネイティブのイベントは、ドキュメントのレベルに既に到達していたからです。React 17 以降は、イベントの伝播は（指示された通りに！）止まるため、あなたが document に書いたハンドラは呼ばれなくなります。

document.addEventListener('click', function() {
  // This custom handler will no longer receive clicks
  // from React components that called e.stopPropagation()
});

このようなコードを修正するには、イベントリスナがキャプチャフェーズで呼ばれるようにコードを変更します。そのためには document.addEventListener の第 3 引数として { capture: true } を渡します：

document.addEventListener('click', function() {
  // Now this event handler uses the capture phase,
  // so it receives *all* click events below!
}, { capture: true });

この方針は、全体的にはむしろ障害に強くなるものだということに注意してください。この変更で、例えば、e.stopPropagation() が React イベントハンドラ外で呼ばれた場合に発生する既存のバグもおそらく修正されることでしょう。言い換えると、React 17 でのイベント伝播は普通の DOM に近くなったということです。

その他の破壊的変更

React 17 での破壊的変更は最小限にとどめてあります。例えば、前のバージョンで非推奨化されたメソッドの削除は行っていません。ただし、我々の経験で比較的安全であった破壊的変更が、少数のみ含まれています。我々のコンポーネントでこれらにより修正する必要があったコンポーネントは 10 万以上あるうちの 20 未満でした。

ブラウザとの整合性向上

イベントシステムに幾つかの小さな変更を加えました：

• よくある誤解を防ぐため、onScroll イベントはバブリングしないようになりました。
• React の onFocus と onBlur イベントはネイティブの focusin と focusout イベントを裏で使うように変更されました。これらは React の既存の挙動とより合致しており、また追加の情報を有していることがあります。
• キャプチャフェーズのイベント（onClickCapture など）は本物のブラウザのキャプチャフェーズのリスナを使うようになります。

これらの変更は React の挙動をブラウザの挙動に近づけて相互運用性を改善するものです。

補足

React 17 は onFocus イベント用に focus ではなく focusin を使うよう裏で変更されましたが、バブリングの挙動に影響はないということに注意してください。React において onFocus イベントは常にバブリングしていましたし、React 17 でも同様です。通常はこれがより有用なデフォルトの動作です。この sandbox で特定のユースケースのために加えることのできるチェックについて見ることができます。

イベントプーリングの廃止

React 17 では「イベントプーリング」による最適化が取り除かれています。モダンブラウザではパフォーマンス向上にならず、経験のある React ユーザですらこの挙動に混乱していました：

function handleChange(e) {
  setData(data => ({
    ...data,
    // This crashes in React 16 and earlier:
    text: e.target.value
  }));
}

上記の問題が起こるのは、React が古いブラウザでのパフォーマンス改善のために複数の異なるイベント間でイベントオブジェクトを再利用しており、その際にイベントのフィールドを null にセットしていたためです。React 16 以前では、イベントを正しく使うために e.persist() を呼ぶか、本来必要になるより先にプロパティを読み出しておく必要がありました。

React 17 では、上記のコードは本来期待される通りに動作するようになります。古いイベントプーリングによる最適化は完全に取り除かれており、必要なときにいつでもイベントのフィールドを読み出せるようになります。

これは振る舞いの変化であるため破壊的変更としてマークしてありますが、実際上は Facebook 内でこれにより壊れたものは何もありませんでした（むしろ幾つかのバグがいつの間にか修正されたかもしれません！）。e.persist() は React イベントオブジェクト内に残りますが、今後は何もしなくなります。

副作用クリーンアップのタイミング

useEffect のクリーンアップ用関数のタイミングをより一貫性のあるものにしました。

useEffect(() => {
  // This is the effect itself.
  return () => {    // This is its cleanup.  };});

ほとんどの副作用は画面の更新を遅延させる必要がないので、React は副作用を画面に更新が反映された直後に非同期的に実行します（ツールチップのサイズ測定や位置合わせなど、副作用が画面の更新をブロックする必要がある稀なケースでは、useLayoutEffect を使うべきです）。

しかし、コンポーネントがアンマウントされる際、副作用のクリーンアップ関数の方は同期的に実行されていました（クラスコンポーネントでの componentWillUnmount が同期的であるのと同様です）。これは大きなアプリでは望ましくないということが分かりました。大きな画面遷移（タブの切り替えなど）がある場合に遅くなってしまうのです。

React 17 では、副作用のクリーンアップ関数が常に非同期的に実行されます。例えば、コンポーネントがアンマウントされる時、クリーンアップ関数は画面が更新された後で実行されます。

これは副作用の本体側がどのように実行されるかに合わせたものです。同期的に実行されることに依存しているような稀なケースでは、useLayoutEffect に変更することができます。

補足

アンマウントされたコンポーネントにおける setState の警告を修正できなくなってしまうのではと心配されているかもしれません。心配は要りません。React はこのケースに対して特別なチェックを行っており、アンマウントとクリーンアップとの間の小さな時間帯に setState の警告を発生させないようになっています。リクエストやインターバルをキャンセルするためのコードはほぼ常に変えずに済みます。

加えて、React 17 は（全コンポーネントにわたる）すべてのクリーンアップ関数を、新しい副作用より前に実行するようになります。React 16 ではコンポーネント内でのみこの順番が保証されているに過ぎませんでした。

起きる可能性のある問題

この変更により動作しなくなったコンポーネントは数個のみでしたが、再利用可能なライブラリではより注意深くテストする必要があるでしょう。問題を引き起こすコードの例は以下のようなものです：

useEffect(() => {
  someRef.current.someSetupMethod();
  return () => {
    someRef.current.someCleanupMethod();
  };
});

問題は someRef.current は書き換え可能であるため、クリーンアップ関数が実行される段階では null に変わっている可能性がある、ということです。解決方法としては、副作用の内部で書き換わる可能性のある値をキャプチャしておきます：

useEffect(() => {
  const instance = someRef.current;
  instance.someSetupMethod();
  return () => {
    instance.someCleanupMethod();
  };
});

我々の eslint-plugin-react-hooks/exhaustive-deps lint ルール（是非使うようにしましょう！）は常にこれを警告してきましたので、このような問題はあまり起きないと思います。

Undefined を返した場合の一貫性のあるエラー

React 16 以前から、コンポーネントが undefined を返すことは常に間違いでした：

function Button() {
  return; // Error: Nothing was returned from render
}

こうなっている理由の一部は、うっかり undefined を返してしまいがちだから、というものです：

function Button() {
  // We forgot to write return, so this component returns undefined.
  // React surfaces this as an error instead of ignoring it.
  <button />;
}

これまで、クラスおよび関数コンポーネントではこのチェックを行っていましたが、forwardRef と memo コンポーネントではこのような返り値のチェックを行っていませんでした。これは我々のコーディングミスによるものです。

React 17 では、forwardRef と memo によるコンポーネントの振る舞いが通常の関数・クラスコンポーネントの振る舞いと合致するようになります。これらから undefined を返すことはエラーになります。

let Button = forwardRef(() => {
  // We forgot to write return, so this component returns undefined.
  // React 17 surfaces this as an error instead of ignoring it.
  <button />;
});

let Button = memo(() => {
  // We forgot to write return, so this component returns undefined.
  // React 17 surfaces this as an error instead of ignoring it.
  <button />;
});

意図的に何もレンダーしたくないという場合には、null を返すようにしてください。

ネイティブのコンポーネントスタック

ブラウザであなたがエラーをスローすると、ブラウザは JavaScript の関数名とそれらの位置を含んだスタックトレースを表示します。しかし、問題を診断するのに JavaScript のスタックトレースでは不十分で React ツリーの階層構造も同じくらい重要だ、ということがよくあります。Button がエラーをスローしたということだけでなく、その Button が React ツリーのどこにあるのかが知りたいでしょう。

この問題を解決するために React 16 で、エラーがあった場合に「コンポーネントスタック」を表示するようにしました。しかし、これはネイティブの JavaScript スタックと比べて劣ったものでした。具体的には、React はソースコード内のどこにその関数が宣言されているのか分からないため、コードをクリックすることができませんでした。また、本番モードではほぼ使いものにならないという問題もありました。minify された JavaScript におけるスタックはソースマップさえあれば自動的に元の関数名に戻せますが、React コンポーネントのスタックにおいては、本番モードでも使えるようにするのかバンドルサイズを小さくするのか選ばなければいけませんでした。

React 17 では、コンポーネントスタックの生成方法が別のメカニズムに変更され、ネイティブ JavaScript スタックと繋ぎ合わせて表示されるようになりました。これにより、本番環境においても完全に名前付きで React のコンポーネントスタックトレースを得られるようになります。

React がこれを実装している方法はいくぶん特殊なものです。現在のところ、ブラウザは関数のスタックフレーム（ソースファイルと位置）を取得する方法を提供していません。このため、React がエラーをキャッチした場合、可能な場合は React は上流にあるコンポーネントのそれぞれから一時エラーをスロー（およびキャッチ）することでコンポーネントスタックを再構成するようになります。これによりクラッシュ時に小さなパフォーマンス低下が起きますが、コンポーネントの型につき 1 度のみです。

興味があれば詳細についてこのプルリクエストで見ることができますが、このメカニズムそのものは、ほぼあなたのコードに影響しません。開発者側から見てこの新機能が意味するのは、コンポーネントスタックをクリック可能になったということ（ネイティブのブラウザのスタックフレームに依存するようになったため）と、本番環境でもそれを普通の JavaScript エラーと同様に読めるようになった、ということです。

これが破壊的変更となっているのは、これを実現するために、React がエラー捕捉後にスタックの上流にある React 関数や React クラスコンストラクタのうちいくつかを再実行する必要があるからです。レンダー関数やクラスコンストラクタは副作用を持つべきではないため（これはサーバレンダリングにおいても重要です）、実際上の問題は起きないはずです。

プライベートなエクスポートの削除

ここで言及すべき最後の破壊的変更は、他のプロジェクトのために公開されていた React の内部構造を一部削除した、ということです。特に、React Native for Web はイベントシステムの内部実装の一部に依存していたのですが、そのような依存は不安定であり、実際によく壊れていました。

React 17 では、このようなプライベートなエクスポートが削除されています。我々の知る限り、React Native for Web がそれを使っていた唯一のプロジェクトであり、既にプライベートなエクスポートに依存しない別の手法にコードの移行を完了しています。

つまり React Native for Web の古いバージョンは React 17 で動作せず、新しいバージョンのみが動作するということです。実際には、React 内部の実装の変化に対応するため React Native for Web は何にせよ新バージョンをリリースする必要があった訳で、大きく話が変わるものではないでしょう。

加えて、ReactTestUtils.SimulateNative ヘルパメソッドも削除しています。これはドキュメントされたこともなく、名前から期待される通りの動作をしたこともなく、イベントシステムに我々が加えた変更によりうまく動作しなくなりました。テストでネイティブのブラウザイベントを発生させる便利な方法が欲しい場合は、代わりに React Testing Library をチェックしてください。

インストール

React 17.0 リリース候補を試してみて、移行作業中に遭遇する問題について issue を報告してください。リリース候補版は安定リリースと比べてバグがある可能性が高いため、本番環境への投入はまだしないでください。

React 17 RC を npm でインストールするには以下のようにします：

npm install react@17.0.0-rc.3 react-dom@17.0.0-rc.3

React 17 RC を Yarn でインストールするには以下のようにします：

yarn add react@17.0.0-rc.3 react-dom@17.0.0-rc.3

CDN 経由で React の UMD ビルドも提供しています：

<script crossorigin src="https://unpkg.com/react@17.0.0-rc.3/umd/react.production.min.js"></script>
<script crossorigin src="https://unpkg.com/react-dom@17.0.0-rc.3/umd/react-dom.production.min.js"></script>

詳細なインストール手順についてはドキュメントを参照してください。

Changelog

React

• Add react/jsx-runtime and react/jsx-dev-runtime for the new JSX transform. (@lunaruan in #18299)
• Build component stacks from native error frames. (@sebmarkbage in #18561)
• Allow to specify displayName on context for improved stacks. (@eps1lon in #18224)
• Prevent 'use strict' from leaking in the UMD bundles. (@koba04 in #19614)
• Stop using fb.me for redirects. (@cylim in #19598)

React DOM

• Delegate events to roots instead of document. (@trueadm in #18195 and others)
• Clean up all effects before running any next effects. (@bvaughn in #17947)
• Run useEffect cleanup functions asynchronously. (@bvaughn in #17925)
• Use browser focusin and focusout for onFocus and onBlur. (@trueadm in #19186)
• Make all Capture events use the browser capture phase. (@trueadm in #19221)
• Don’t emulate bubbling of the onScroll event. (@gaearon in #19464)
• Throw if forwardRef or memo component returns undefined. (@gaearon in #19550)
• Remove event pooling. (@trueadm in #18969)
• Stop exposing internals that won’t be needed by React Native Web. (@necolas in #18483)
• Attach all known event listeners when the root mounts. (@gaearon in #19659)
• Disable console in the second render pass of DEV mode double render. (@sebmarkbage in #18547)
• Deprecate the undocumented and misleading ReactTestUtils.SimulateNative API. (@gaearon in #13407)
• Rename private field names used in the internals. (@gaearon in #18377)
• Don’t call User Timing API in development. (@gaearon in #18417)
• Disable console during the repeated render in Strict Mode. (@sebmarkbage in #18547)
• In Strict Mode, double-render components without Hooks too. (@eps1lon in #18430)
• Allow calling ReactDOM.flushSync during lifecycle methods (but warn). (@sebmarkbage in #18759)
• Add the code property to the keyboard event objects. (@bl00mber in #18287)
• Add the disableRemotePlayback property for video elements. (@tombrowndev in #18619)
• Add the enterKeyHint property for input elements. (@eps1lon in #18634)
• Warn when no value is provided to <Context.Provider>. (@charlie1404 in #19054)
• Warn when memo or forwardRef components return undefined. (@bvaughn in #19550)
• Improve the error message for invalid updates. (@JoviDeCroock in #18316)
• Exclude forwardRef and memo from stack frames. (@sebmarkbage in #18559)
• Improve the error message when switching between controlled and uncontrolled inputs. (@vcarl in #17070)
• Keep onTouchStart, onTouchMove, and onWheel passive. (@gaearon in #19654)
• Fix setState hanging in development inside a closed iframe. (@gaearon in #19220)
• Fix rendering bailout for lazy components with defaultProps. (@jddxf in #18539)
• Fix a false positive warning when dangerouslySetInnerHTML is undefined. (@eps1lon in #18676)
• Fix Test Utils with non-standard require implementation. (@just-boris in #18632)
• Fix onBeforeInput reporting an incorrect event.type. (@eps1lon in #19561)
• Fix event.relatedTarget reported as undefined in Firefox. (@claytercek in #19607)
• Fix “unspecified error” in IE11. (@hemakshis in #19664)
• Fix rendering into a shadow root. (@Jack-Works in #15894)
• Fix movementX/Y polyfill with capture events. (@gaearon in #19672)
• Use delegation for onSubmit and onReset events. (@gaearon in #19333)
• Improve memory usage. (@trueadm in #18970)

React DOM Server

• Make useCallback behavior consistent with useMemo for the server renderer. (@alexmckenley in #18783)
• Fix state leaking when a function component throws. (@pmaccart in #19212)

React Test Renderer

• Improve findByType error message. (@henryqdineen in #17439)

Concurrent Mode (Experimental)

• Revamp the priority batching heuristics. (@acdlite in #18796)
• Add the unstable_ prefix before the experimental APIs. (@acdlite in #18825)
• Remove unstable_discreteUpdates and unstable_flushDiscreteUpdates. (@trueadm in #18825)
• Remove the timeoutMs argument. (@acdlite in #19703)
• Disable <div hidden /> prerendering in favor of a different future API. (@acdlite in #18917)
• Add unstable_expectedLoadTime to Suspense for CPU-bound trees. (@acdlite in #19936)
• Add an experimental unstable_useOpaqueIdentifier Hook. (@lunaruan in #17322)
• Add an experimental unstable_startTransition API. (@rickhanlonii in #19696)
• Using act in the test renderer no longer flushes Suspense fallbacks. (@acdlite in #18596)
• Use global render timeout for CPU Suspense. (@sebmarkbage in #19643)
• Clear the existing root content before mounting. (@bvaughn in #18730)
• Fix a bug with error boundaries. (@acdlite in #18265)
• Fix a bug causing dropped updates in a suspended tree. (@acdlite in #18384 and #18457)
• Fix a bug causing dropped render phase updates. (@acdlite in #18537)
• Fix a bug in SuspenseList. (@sebmarkbage in #18412)
• Fix a bug causing Suspense fallback to show too early. (@acdlite in #18411)
• Fix a bug with class components inside SuspenseList. (@sebmarkbage in #18448)
• Fix a bug with inputs that may cause updates to be dropped. (@jddxf in #18515 and @acdlite in #18535)
• Fix a bug causing Suspense fallback to get stuck. (@acdlite in #18663)
• Don’t cut off the tail of a SuspenseList if hydrating. (@sebmarkbage in #18854)
• Fix a bug in useMutableSource that may happen when getSnapshot changes. (@bvaughn in #18297)
• Fix a tearing bug in useMutableSource. (@bvaughn in #18912)
• Warn if calling setState outside of render but before commit. (@sebmarkbage in #18838)

このブログはアーカイブされています。最新の記事は ja.react.dev/blog でご覧ください。

本日、React 16.13.0 をリリースします。このリリースには、バグ修正と、今後のメジャーリリースに備えるための新しい非推奨の警告が含まれています。

新たな警告

レンダー中のいくつかの更新に関する警告

React コンポーネントは、レンダー中に他のコンポーネントに副作用を起こしてはいけません。

レンダー中に setState を呼び出すことはサポートされていますが同じコンポーネントに対してのみ可能です。別のコンポーネントのレンダー中に setState を呼び出すと、警告が表示されるようになりました。

Warning: Cannot update a component from inside the function body of a different component.

この警告は、意図しない状態変更によって引き起こされるアプリケーションのバグを見つけるのに役立ちます。レンダーの結果として他のコンポーネントの状態を意図的に変更したいという稀なケースでは、setState 呼び出しを useEffect にラップすることができます。

スタイルルールが矛盾している場合の警告

ある CSS プロパティの長い記法と短い記法を同時に含む style を動的に適用する場合、特定の更新の組み合わせにより、スタイリングの一貫性が失われることがあります。例えば、以下のようになります。

<div style={toggle ? 
  { background: 'blue', backgroundColor: 'red' } : 
  { backgroundColor: 'red' }
}>
  ...
</div> 

この <div> は toggle の値に関係なく常に背景色が赤になると思われるかもしれません。しかし、このデモを見てわかるように、toggle の値を true と false の間で切り替えると、背景色は red から始まり、その後 transparent と blue の間で交互に切り替わります。

React は、スタイルルールの競合を検出し、警告をログに記録するようになりました。この問題を修正するには、同一の CSS プロパティの短い記法と長い記法のバージョンを style プロパティ内で混在させないようにしてください。

一部の非推奨 string ref に関する注意点

String ref（文字列形式の ref）は古いレガシー API であり、既に勧められておらず、将来的に正式に非推奨となる予定です。

<Button ref="myRef" />

（String ref と異なり、一般的な ref 自体は完全にサポートされ続けますので混同しないようにしてください）

将来的には、string ref からの移行を自動化するスクリプト (“codemod”) を提供する予定です。しかし、まれに自動移行できないケースがあります。このリリースでは、非推奨化に先立ち、そのようなケースにのみ警告を追加しています。

例えば、レンダープロップパターンと一緒に string ref を使用した場合に発生します。

class ClassWithRenderProp extends React.Component {
  componentDidMount() {
    doSomething(this.refs.myRef);
  }
  render() {
    return this.props.children();
  }
}

class ClassParent extends React.Component {
  render() {
    return (
      <ClassWithRenderProp>
        {() => <Button ref="myRef" />}
      </ClassWithRenderProp>
    );
  }
}

このようなコードはしばしばバグを示します（ref は ClassParent で利用できると思われるかもしれませんが、代わりに ClassWithRenderProp に置かれてしまいます）。

このようなコードはお持ちでない可能性が高いでしょう。もしそのようなコードがあって、それが意図的なものであれば、代わりに React.createRef() を使うよう変更してください：

class ClassWithRenderProp extends React.Component {
  myRef = React.createRef();
  componentDidMount() {
    doSomething(this.myRef.current);
  }
  render() {
    return this.props.children(this.myRef);
  }
}

class ClassParent extends React.Component {
  render() {
    return (
      <ClassWithRenderProp>
        {myRef => <Button ref={myRef} />}
      </ClassWithRenderProp>
    );
  }
}

補足

この警告を見るためには、Babel プラグインとして babel-plugin-transform-react-jsx-self がインストールされている必要があります。これは開発モードでのみ有効にする必要があります。

Create React App を使っているか、Babel 7 以降で “react” プリセットを使っている場合、既にデフォルトでこのプラグインはインストールされています。

React.createFactory の非推奨化

React.createFactory は React 要素を作成するためのレガシーのヘルパです。このリリースでは、このメソッドに非推奨の警告が追加されています。これは将来のメジャーバージョンで削除される予定です。

React.createFactory の使用法を通常の JSX で置き換えてください。代わりに、この 1 行ヘルパをコピー＆ペーストするか、ライブラリとして公開することもできます。

let createFactory = type => React.createElement.bind(null, type);

全く同じことをしています。

ReactDOM.unstable_createPortal の非推奨化、ReactDOM.createPortal に変更を

React 16 がリリースされたとき、createPortal は公式にサポートされる API になりました。

しかし、unstable_createPortal を採用している少数のライブラリが動作するように、unstable_createPortal をサポートされたエイリアスとして残していました。今後この不安定なエイリアスは非推奨とします。unstable_createPortal の代わりに createPortal を直接使ってください。これは全く同じシグネチャを持っています。

その他の改良事項

hydration の警告におけるコンポーネントスタック

React は開発者向け警告にコンポーネントスタックを追加し、開発者がバグを特定してプログラムをデバッグできるようにしています。今回のリリースでは、以前はコンポーネントスタックが存在しなかった多くの開発者向け警告に、それが追加されました。例として、以前のバージョンにあったこのハイドレーション警告を考えてみましょう。

コードとともにエラーを指摘していますが、どこにエラーが存在しているのか、次に何をすればいいのかが明確ではありません。このリリースでは、この警告にコンポーネントスタックが追加され、以下のようになりました。

これにより、問題がどこにあるのかが明確になり、より早くバグの場所を特定して修正することができます。

注目すべきバグ修正

このリリースには、他にもいくつかの注目すべき改善点が含まれています。

• Strict 開発モードでは、React はライフサイクルメソッドを 2 回呼び出し、好ましくない副作用の可能性を洗い出すようにしています。このリリースでは、その動作を shouldComponentUpdate に追加しています。これは、shouldComponentUpdate に副作用がない限り、ほとんどのコードには影響しないはずです。これを修正するには、副作用のあるコードを componentDidUpdate に移動してください。
• Strict 開発モードでは、レガシーコンテクスト API の使用に関する警告には、警告のトリガとなったコンポーネントのスタックが含まれていませんでした。このリリースでは、欠けていたスタックが警告に追加されます。
• 無効な（disabled の）<button> 要素に対して onMouseEnter がトリガされないようになりました。
• ReactDOM は v16 を公開して以来、version のエクスポートがありませんでした。このリリースではそれが改めて追加されました。アプリケーションロジックでの使用はお勧めしませんが、同じページ上の ReactDOM のバージョン不一致や複数バージョンに関わる問題をデバッグする際に便利です。

これらの問題やその他の問題を解決してくれた貢献者に感謝します。完全な changelog は下記を参照してください。

インストール

React

React v16.13.0 は npm レジストリで利用可能です。

Yarn で React 16 をインストールするには、下記を実行します：

yarn add react@^16.13.0 react-dom@^16.13.0

npm で React 16 をインストールするには、下記を実行します：

npm install --save react@^16.13.0 react-dom@^16.13.0

また、CDN 経由で React の UMD ビルドも提供しています：

<script crossorigin src="https://unpkg.com/react@16/umd/react.production.min.js"></script>
<script crossorigin src="https://unpkg.com/react-dom@16/umd/react-dom.production.min.js"></script>

詳細なインストール方法については、ドキュメントを参照してください。

変更履歴

React

• Warn when a string ref is used in a manner that’s not amenable to a future codemod (@lunaruan in #17864)
• Deprecate React.createFactory() (@trueadm in #17878)

React DOM

• Warn when changes in style may cause an unexpected collision (@sophiebits in #14181, #18002)
• Warn when a function component is updated during another component’s render phase (@acdlite in #17099)
• Deprecate unstable_createPortal (@trueadm in #17880)
• Fix onMouseEnter being fired on disabled buttons (@AlfredoGJ in #17675)
• Call shouldComponentUpdate twice when developing in StrictMode (@bvaughn in #17942)
• Add version property to ReactDOM (@ealush in #15780)
• Don’t call toString() of dangerouslySetInnerHTML (@sebmarkbage in #17773)
• Show component stacks in more warnings (@gaearon in #17922, #17586)

Concurrent Mode (Experimental)

• Warn for problematic usages of ReactDOM.createRoot() (@trueadm in #17937)
• Remove ReactDOM.createRoot() callback params and added warnings on usage (@bvaughn in #17916)
• Don’t group Idle/Offscreen work with other work (@sebmarkbage in #17456)
• Adjust SuspenseList CPU bound heuristic (@sebmarkbage in #17455)
• Add missing event plugin priorities (@trueadm in #17914)
• Fix isPending only being true when transitioning from inside an input event (@acdlite in #17382)
• Fix React.memo components dropping updates when interrupted by a higher priority update (@acdlite in #18091)
• Don’t warn when suspending at the wrong priority (@gaearon in #17971)
• Fix a bug with rebasing updates (@acdlite and @sebmarkbage in #17560, #17510, #17483, #17480)