本記事はReact v18.0のリリース記事"React v18.0"を自分自身のために翻訳しメモをとったものです。元記事を全て翻訳しようという試みではありません。正確な内容は元の記事をご覧ください。

React v18.0

前回の我々の投稿では、アプリケーションをReact18に更新する段階的なインストラクションを共有した。この投稿では、我々はReact 18において何が新しくなったのかの概要を提供し、それら機能の意味するところを説明する。

我々の最新のメジャーバージョンには、automatic batchingのような即時適用（out-of-the-box）される改善や、startTransitionやSuspenceをサポートするstreaming server-side renderingなどのような新しいAPIを含んでいる。

React 18の機能を多くは、新しいconcurrrent rendererの上に構築されており、それらは大きな可能性をアンロックする舞台裏の変化である。Concurrent Reactはオプトインである。それは、concurrent機能を使うときのみ有効であるが、我々はこの機能がアプリケーションを作るのに大きなインパクトを与えると考えている。

我々は、数年に渡ってReactにおける並行性（concurrency）のサポートについて研究、開発をおこなってきた。そして、我々は、ユーザーが漸次的に適用できるような方法を提供するように努めてきた。昨夏、我々はコミュニティのエキスパートたちからのフィードバックを収集し、すべてのReactエコシステムがスムースにアップグレードできることを確信するためReact 18 Working Groupを作った。

以下はConcurrent Renderingから始まるこのリリースで何が期待されるのかに関する概要である。

Concurrent Reactとは何か？

React 18において最も重要な更新は、ユーザーが並行性（concurrency）について考えなくてもよいようにすることである。我々はほとんどの開発者にとってこれが実現するが、ライブラリのメンテナーにとっては少し複雑になってくると考えている。

並行性とは本質的には機能ではない。それは、Reactが同時に複数のUIのバージョンを準備することを可能にする、舞台裏のメカニズムである。並行性のことは実装の詳細であると考えることができる。その機能はアンロックされるものであるのでそう考えるのは価値のあることだ。Reactは優先度付きキューやmultiple buffering などのような洗練された技術をその内部実装に使用している。しかし、それらの概念を我々のpublicなAPIにおいて知っている必要はない。

我々がAPIを設計するとき、我々は開発者に対して実装の詳細（これはReactのレンダリングモデルのコアの基本的な更新である）を隠すように努めている。 Reactの開発者（Reactのユーザー）として、あなたはUXをどんなふうにしたいかに注力し、ReactはそのUXをどのように実現するかを扱う。なので我々はReact開発者が裏で動いている並行処理（concurrency works）について知ることを期待していない。

しかし、Concurrent Reactは典型的な実装の詳細よりかは重要であり、なぜならばそれはReactの中心的なレンダリングモデルを根本的にアップデートするからである。なので、並行処理（concurrency works）がどのように行われるかについて知ることは特別重要であるということはないが、高い視点からそれが何であるかを知ることには価値があるかもしれない。

Concurrent Reactの重要な特性は、レンダリングが一時停止可能であることである。React 18にアップグレードして、 concurrent featuresを追加する前、更新は以前のバージョンのReactと同じようにレンダリングされる、つまり単一で一時停止不可能な、同期的なトランザクション（cynchronous transaction）である。Synchronous renderingを使うと、一度更新がレンダリングを開始すると、その結果がスクリーンに表示されユーザーがその表示を見るまでレンダリング処理を停止することができない。

Concurrent renderではこれはいつも起こることではない。Reactは更新のレンダリングを開始し、途中で止めて、それからのちにレンダリング処理を継続させるかもしれない。その処理の中で、Reactは進行中のレンダリングを捨てるかもしれない。Reactはたとえあるレンダリングが停止されたとしても一貫してUIを表示することを保証する。これを行うため、全てのツリーを評価するたびReactは最後までDOMの変更を行うことを待つ。この機能を使うと、Reactはメインスレッドをブロックすることなくバックグラウンドで新たなスクリーンを準備することができる。これはたとえその途中に大きなレンダリングタスクがあっても、UIがユーザーの入力に対して即時に応答でき、滑らかなUXを作り出すことができるということである。

もう一つの例は再利用可能なstateである。Concurrent ReactはスクリーンからUIの一部を取り除き、そして前回のstateを用いてあとでそれらを追加することができる。例えば、ユーザーがタブを使ってスクリーンから離れて戻ってきたとき、Reactは前回そうだったのと同じstateによって前回のスクリーンを回復すべきである。これからくるマイナーアップデートでは、我々はこのパターンを実装した<Offscreen>という新たなコンポーネントを提供することを計画中である。同様にOffscreenはユーザーにUIを見せる前にバックグラウンドでUIを用意することを可能にする。

Concurrent renderingはReactにおける強力な新たなツールであり、Suspence、transition、streaming server renderingなどを含めほとんどの新たな機能はそれを最大限利用して構築されている。しかし、React 18はこの新たな基礎の上に構築するという目的の始まりに過ぎない。

Concurrent Featureの漸次的な適用

技術的には、concurrent renderingは破壊的変更である。なぜならば、concurrent renderingはinterruptibleであり、それを可能にしたときコンポーネントの挙動は少し異なるからである。

我々のテストにおいて、我々は幾千のコンポーネントをReact 18へとアップグレードしてきた。我々が見てきたのは、ほぼ全ての既存のコンポーネントがconcurrent renderingを使ってその他の変更なしに"ただ動く"ことであった。しかし、いくつかのコンポーネントは追加で移行のための努力が必要であった。大抵その変更は小さいものであるが、あなた自身のペースでそれら変更を行う余地がある。React 18における新たなレンダリングの挙動は、新しい機能を使った部分でのみ有効になる。

全体のアプグレードの戦略は既存のコードを破壊することなくReact 18であなたのアプリケーションを走らせるだろう。それから、自分のペースでconcrurrent featuresを追加し始めることができる。あなたは開発中に<StrictMode>を使うことによって表面的なconcurrencyに関連したバグを補助することができる。Strict Modeはプロダクションの挙動には影響しないが、開発中には警告を記録し、そして冪等であることが期待される関数の2回呼び出しが行われる。全てのバグを補足できるわけではないが、ほとんどの一般的なミスを効果的に防ぐことができる。

React 18へアップグレードが終わったあと、すぐにconcurrent featuresを利用し始めることができる。例えば、startTransitionはユーザーインプットのブロックなしにスクリーン間を遷移すること可能となる。また、useDeferredValueは高価な再レンダリングの影響を小さくすることができる。

しかし、長い目で見れば、我々は開発者たちにconcurrentが有効なライブラリやフレームワークを利用することによってアプリケーションにconcurrencyを加えることを主流とするように期待している。ほとんどのケースでは、concurrent APIに直接関わりたくないだろう。例えば、新たなスクリーンに遷移するときはいつも開発者がstartTransitionを呼ぶ代わりに、ルーターライブラリを自動的にstartTransitionで遷移を自動的にラップする。

ライブラリがconcurrent機能を使えるようになるのにはいくらか時間がかかるかもしれない。我々はライブラリがconcurrent featuresを利用しやすいように新たなAPIを提供した。それまでの間はメンテナーはReactのエコシステムの段階的な移行をおこなっているためお待ちください。

さらなる情報として前回の投稿をご覧ください。How to upgrade to React 18

データフレームワークにおけるSuspense

React 18ではRelay、Next.js、Hydrogen、Remixといったopinionatedなフレームワークにおいてデータ取得のために Suspenseを使い始めることができる。Suspenseを使用したアドホックなデータ取得は可能ではあるが、一般的な戦略としてはまだ推奨されない。

将来的には、おそらくopinionatedなフレームワークを使用することなく、Suspenseを使ってデータにアクセスする簡単なプリミティブを提供するかもしれない。しかし、Suspenseはルーター、データレイヤー、サーバーレンダリング環境といったアプリケーションアーキテクチャに深く統合されたときに最もよく機能する。したがって当分の間我々はライブラリやフレームワークがReactのエコシステムにおいて重要な役割を果たすと予測している。

Server Componentはまだ開発中である

Server Componentはこれから提供される予定の機能であり、これによって伝統的なサーバーレンダリングのパフォーマンスの改善とクライアントサイドのリッチなインタラクティビティが組み合わされるので開発者はサーバーとクライアント間の橋渡しができる。 Server Componentは本来的にはConcurrent Reactと結合するものではないが、 Suspenseとstreaming server renderingのようなcuncurrent featuresと協働するのがベストであるように設計されている。

Server Componentはまだ実験的であるが、18.xのリリースの最初のバージョンでリリースすることを予定している。しばらくの間は我々は、さらなるプロポーザルと適用のための準備のためNext.js、Hydrogen、Remixで作業をする。

React 18でなにが新しくなったのか

新機能：Automatic Batching

Automatic batching for fewer renders in React 18を一部翻訳済みなので割愛。

新機能：Transitions

New feature: startTransition #41を一部翻訳済みなので割愛。

新しいSuspense機能

SuspenseはReactのプログラミングモデルの中で第一級の宣言的コンセプトである「UIがロードされている状態」を作り出す。これにより我々はその上により高いレベルの機能を作ることができるようになった。

我々は数年前に限定的な機能を持ったバージョンのSuspenseを導入した。しかし、サポートしているユースケースはReact.lazyを使ったコード分割だけであって、サーバー上でのレンダリングは全くサポート外であった。

React 18ではサーバーでのSuspenseのサポートを追加し、concurrent rendering機能を使ってその可能性を拡大してきた。

React 18のSuspenseはtransition APIと組み合わさったとき最もよく機能する。もしtransitionの間一時停止（suspend）すれば、Reactはすでに見えているコンテンツがフォールバックに置き換わることを妨げるだろう。その代わりにReactは健全でないロード状態を防ぐために、十分なデータがロードされるまでレンダーを遅らせるだろう。

さらなる情報が必要なときはSuspense in React 18をご覧ください。

（以下翻訳中）

新しいクライアントとサーバーのAPI

このリリースではクライアントとサーバーにおけるレンダリングのためにAPIを再設計する機会をとった。これらの変更ではユーザーはReact 18の新しいAPIへアップグレードする間にReact 17の古いAPIを継続して利用可能である。

React DOM Client

以下の新しいAPIがreact-dom/clientからエクスポートされている。

createRoot: renderやunmoutのためのルートを作成する新たなメソッドである。React.DOM.renderの代わりに使用する。 React 18の新たな機能はこれを使わないと動かない。
hydrateRoot: サーバーでレンダーされたアプリケーションをハイドレーションするためのメソッドである。新しいReact DOMサーバーAPIと統合する中でReactDOM.hydrateの代わりに使用する。React 18の新たな機能はこれを使わないと動かない。

createRootとhydrateRootはレンダリングやハイドレーションの間に起こったエラーから回復したときに通知したい場合にonRecoverableErrorと呼ばれる新たなオプションを受け取ることができる。デフォルトではReactはreportErrorかブラウザのためにconsole.errorを使う。

React DOM Server

これらの新しいDOMはreact-dom/serverからエクスポートされており、サーバーにおけるstream suspenseを全面的にサポートしている。

renderToPipeableStream: Node環境でのストリーミング用
renderToReadableStream: DenoやCloudflare workersなど現代的な実行環境のためのもの。

新しいStrict Modeの挙動

将来的にReactがstateを保存しながらUIの一部分を追加したり取り除いたりできる機能を追加したいと考えている。例えば、ユーザーがタブを変えスクリーンから離れ戻ってきたとき、Reactは前回のスクリーンを即座に表示すべきだろう。これを実現するためにReactは前回と同じstateを使ってアンマウントしたり、再マウントしたりするだろう。

この機能はReactアプリのより良いパフォーマンスにつながる、しかしこの機能はコンポーネントに複数回マウントされたり破棄される副作用に対する回復力を要求する。ほとんどの副作用は変更なしでもうまく動くが、マウントされるときや破棄されるときに一度だけ処理されることを想定された副作用がある。

これらの課題を表面的に補助するために、React 18はStrict Modeで新たに開発時のみにおけるチェックを導入した。このチェックはコンポーネントが初めてマウントされるときは毎回、自動的に全てのコンポーネントをアンマウントし再マウントして 2回目のマウントにおいて前回のステートを保存する。

この変更の前には、Reactはコンポーネントをマウントして副作用を生成した。

* React mounts the component.
  * Layout effects are created.
  * Effects are created.

React 18でStrict Modeを使うと、開発環境でコンポーネントのReactはアンマウントと再マウントをシミュレートする。

* React mounts the component.
  * Layout effects are created.
  * Effects are created.
* React simulates unmounting the component.
  * Layout effects are destroyed.
  * Effects are destroyed.
* React simulates mounting the component with the previous state.
  * Layout effects are created.
  * Effects are created.

新しいHooks

useId

useIdはハイドレーションの不整合を避けるためにクライアントとサーバーの両方で一意なIDを生成するためのhookである。これは一意のIDを要求するアクセシビリティAPIと統合しているコンポーネントライブラリで役に立つことを主要としている。これはReact 17より前で存在していた課題を解決するが、新しいstreaming server rendererがHTMLを提供する方法により React 18ではさらに重要となる。

useTransition

useTransitionとstartTransitionを使うと緊急ではないstateの更新をマークすることができる。その他のstate更新はデフォルトでは緊急であると判断される。Reactは緊急のstate更新が緊急ではないstate更新をインタラプトすることができる。

useDeferredValue

useDeferredValueを使うとツリーの重要でない部分の再レンダリングを遅らせることができる。これはdebouncingに似ているが、それに比べていくつか有利な点がある。Reactは最初のレンダーがスクリーンに反映された直後に遅延されたレンダーを試みることができるので固定の遅延時間はない。

翻訳時のメモ：debouncingではイベントハンドラ内でsetTimeoutを用いてstateの更新を100 ms後など固定された時間に設定する。 1回目のイベント発火の後、100 ms以内に行われた次の同じイベント発火では1回目でスケジュールされたstate更新処理をキャンセルする。こうすることで一部の無駄なstateの更新をキャンセルすることができるが、この実装だとどんなにCPUの性能がよくても最低100 ms間はstateの更新を待つことになる。

useSyncExternalStore

useSyncExternalStoreはストアに対する更新を同期的に強制することで、外部ストアがconcurrent readsをサポートするのに役立つ。これは外部データソースを購読する実装をするときに useEffectの必要性を取り除くもので、Reactのための外部ステートを統合している全てのライブラリはこれを使うことを推奨する。

useInsertionEffect

useInsertionEffectはCSS-in-JSのライブラリがレンダーにおけるスタイル注入のパフォーマンス的課題に取り組むのに役立つ。すでにCSS-in-JSを制作しているのでないならば、これを使うことは期待されていない。このhookはDOMが変更された後に実行されるが、新たなレイアアウトのeffectの前に新しいレイアウトを読む。これはReact 17以前の既知の問題を解決するが、React 18においてはそれ以上に重要なことである。なぜならば、 Reactはcuncurrent renderingの間ブラウザに譲歩して、レイアウトを再計算する機会を与えるからだ。

「React v18.0」を翻訳しながら理解する