startTransitionはstateの更新の優先順位をReactに伝えるためのAPIである。startTransitionを使用することでUIの即応性を保ったままコストの大きなstateの更新行うことができる。

本記事は<a href="https://github.com/reactwg/react-18/discussions/41" target="_blank" rel="nofollow noopener noreferrer">&quot;New feature: startTransition #41&quot;</a>
を自分自身がその内容を理解するという目的で翻訳したものです。元の文全てを翻訳したものではありません。
<h2>概要</h2>
React 18では大規模なスクリーンの更新の間にもアプリケーションをレスポンシブに保つための新しいAPIが導入される。この新しいAPIでは、特定の更新を&quot;transitions&quot;としてマークすることでユーザーインタラクションを大きく改善する。
Reactはstateの遷移(transition)の間に視覚的なフィードバックを与え、遷移の間にもブラウザをレスポンシブに保つ。
<h2>どんな問題を解決するのか？</h2>
動きが滑らかで応答性の高いアプリを構築することがいつも簡単であるとは限らない。ボタンをクリックしたりinputに文字を入力したりすると、スクリーン上で多くのことが起こる。そしてこれはページをフリーズさせたり、全ての処理が終わるまでの間ハングしたりすることにつながる。
例えば、データリストをフィルタリングするinputに文字を入力することを考える。実装者はデータをフィルタリングとinputフィールドの値を制御するためにstateにそのフィールドの値を保持する必要があるだろう。コードは次のようになるはずだ。
<pre><code class="language-js">// inputの値と検索結果を更新
setSearchQuery(input);
</code></pre>
ここで開発者はユーザーが文字をタイプするとinputの値を更新して新しい値を使用してリストを検索しその結果を表示するように実装する。スクリーン上の大きな更新において、これは全てのレンダリングの間にページ上のラグを引き起こす可能性があり、タイピングやその他のインタラクションを遅く感じさせる。もしリストがそれほど長くなくても、アイテム自体が複雑でキーストロークごとにその結果が異なる可能性がありこれらのレンダリングの最適化のはっきりした方法がないかもしれない。
概念的にはこの問題には起こるべき二つの異なる更新が存在する。ひとつ目の更新は緊急の更新（urgent update）であり、inputフィールドの値の更新や潜在的にinputフィールド周りの更新である。二つ目の更新は、緊急性の低い更新（less urgent update）であり、検索結果を表示するための更新である。
<pre><code class="language-js">// 緊急: 何をタイプしたか
setInpuValue(input);

// 緊急ではない：結果の表示
setSearchQuery(input);
</code></pre>
ユーザーは一つ目の更新（urgent updateのこと）に対しては、即時の更新を期待する。通常ブラウザのこの種のインタラクションの取り扱いは速いからだ。しかし二つ目の更新は少し遅延するかもしれない。ユーザーはその更新が直ちに完了することは期待しておらず、多くの処理を行なっていると予測しているのでそれでよい。（実際に開発者はよくdebouncingなどのテクニックを用いてこの種の更新を意図的に遅延させることがある.）
React18以前では、全ての更新は緊急的にレンダーされていた。これは上記の二つのstateが同時にレンダーされていることを意味しており、ユーザーが彼らのインタラクションから即時受け取るはずのフィードバックを全てがレンダーされるまでブロックしてしまう。我々に足りなかったものはReactに「どの更新が緊急であり、どの更新が緊急でないか」を伝える方法である。
<h2><code>startTransition</code>はどのように役立つのか？</h2>
<code>startTransition</code> APIは更新を&quot;transitions&quot;としてマークすることでこの問題を解決する。
<pre><code class="language-js">import { startTransition } from &#x27;react&#x27;;

// 緊急：何をタイプしたか
setInputValue(input);

//内側にあるstateの更新はすべてtransitionとしてマークする
startTransition(() =&gt; {
 // Transition: 結果を表示する
 setSearchQuery(input);
});

</code></pre>
<code>startTransition</code>の中に囲われている更新は緊急でない（non-urgent）更新として扱われ、クリックやキーボードの押下などのより緊急の更新が生じると一時停止される。もし、transitionがユーザーによって（例えば続けて複数文字をタイピングするなどして）一時停止されれば、Reactはそのstateの終了しなかったレンダリング処理を投げ出し（throw out）、最新の更新のみをレンダーする。
例えUIの大きな変更を伴うとしてもtransitionは多くのインタラクションをsnappyにしてくれる。また、もはや関係なくなったコンテンツをレンダリングする無駄な時間を削減することにもつながる。
<h2>Transitionとは何なのか？</h2>
我々はstateの更新を二つに分類した。
<ul>
<li>緊急の更新（urgent Update）はタイピングやクリック、キーの押下などのインタラクションを直接反映する。</li>
<li>遷移の更新（transition update）はUIが他の見た目に変化する。</li>
</ul>
タイピング、クリック、キーの押下などurgent updateは物理的なモノがどのように振る舞うかに関する私たちに直感に合うように即時のレスポンスが必要である。そうでなければ彼ら（ユーザーは）「間違えた」と感じる。しかし、transitionsに関して私たちは画面上のすべての中間値が見えることを予測していない点で（urgent updateとは）異なる。
例えばあなたがドロップダウンでフィルターを選択する際に、フィルターボタンをクリックしたときフィルターボタンそれ自身は直ちにレスポンスを返すことを予期しているだろう。しかし実際の結果は分離して遷移する。（うまく訳せなかった。）小さな遅延は気にされることなく、大抵予期されるものである。そしてもしあなたが結果のレンダリングの終了前にフィルターを変更すると、あなたは最新の結果だけを見ることができる。
典型的なReactのアプリでは、ほとんどの更新は概念的にtransition updatesである。しかし後方互換性の観点からtransitionsはオプトインである。デフォルトではReact18は更新をurgentとして扱い、更新を<code>startTransition</code>囲うことでtransitionとして扱うことができる。
<h2><code>setTimeout</code>とどのように異なるのか？</h2>
上記の問題の一般的な解決策は「緊急でない更新」をsetTimeoutでラップすることである。
<pre><code class="language-js">// 何をタイプしたか表示する
setInputValue(input);
// 結果を表示する
setTimeout(() =&gt; {
 setSearchQuery(input);
}, 0);
</code></pre>
これは「緊急の更新」がレンダリングされるまで「緊急でない更新」を遅延させる。Throttlingとdebouncingはこのテクニックの一般的なバリエーションである。
<code>startTransition</code>と<code>setTimeout</code>の重要な違いは、<code>setTimeout</code>とは違い<code>startTransition</code>ではラップしたコードが後に実行されるようにスケジュールされることはないということだ。つまり、<code>startTransition</code>によってラップされたコードは直ちに実行される。<code>startTransition</code>に渡された関数は、同期的に実行されるがその中の全ての更新は&quot;transitions&quot;としてマークされる。
Reactはどのように更新をレンダーするかを決める過程でこの情報を使用する。これはタイムアウトでラップしたときよりも更新をのレンダリングをより早く開始できるということを意味する。速いデバイスでは二つの更新の間には小さな遅延しかない。そして遅いデバイスでは遅延は大きくなるが、UIはレスポンシブな状態が保たれるだろう。
もう一つの重要な違いは<code>setTimeout</code>を用いた大きな更新では依然としてタイムアウトの直後ページをロック状態にしてしまうということである。もしユーザーがタイムアウト発火のときにページに入力するなど、インタラクションを行なっているなら、彼らはページとインタラクションするのをブロックされるだろう。しかし<code>startTransition</code>を使ってマークされたstateの更新は一時停止可能（ユーザーのインタラクション関連のstate更新を優先するために一時停止するという意味だと思う）であるのでページをロック状態にすることはない。ブラウザは異なるコンポーネントのレンダリング間の小さな違いの中でイベントを取り扱うようになる。（うまく訳せなかった。）ユーザーの入力が変化したときReactはユーザーにとってもはや関心のない何かをレンダリングしようとはしない。
<code>setTimeout</code>は単純な更新の遅延であるので、ローディングインジケーターの表示には非同期のコードを書く必要がありそのようなコードは壊れやすい。
transitionを使うとReactはstateの保留を追跡することがでる。そしてReactはそれをtransitionの現在のstateを用いて更新し、それらを待っている間のローディングフィードバックをユーザーに表示する機能を提供する。
<h2>transitionが保留されている間何をすればよいのか？</h2>
ベストプラクティスとして、バックグラウンドで処理が起きていることをユーザーに知らせる必要があるだろう。このために我々はtransitionsのための<code>isPending</code>フラグと共にhookを提供する。
<pre><code class="language-js">import { useTransition } from &#x27;react&#x27;;

const [isPending, startTransition] = useTransition();
</code></pre>
transitionが保留中ならば<code>isPending</code>はtrueであり、ユーザーの待ち時間にスピナーを表示することができる。
<pre><code class="language-js">{isPending &amp;&amp; &lt;Spinner /&gt;}
</code></pre>
transitionでラップするstateの更新は同じコンポーネントのstateである必要はない。例えば検索の入力内のスピナーは検索結果の再レンダリングプロセスを反映することができる。（よくわからなかった。）
<h2>なぜ単により速いコードを書かないのか?</h2>
高速なコードを書くことと不必要な再レンダリングを避けることは依然としてパフォーマンス最適化の良い方法である。
Transitionはそれを補完する。Transitionは新たなスクリーンを表示するなど大幅なUIの変化の間にさえもUIをレスポンシブな状態に保つ。これは既存の戦略を使った最適化では困難なことである。不必要な再レンダリングが存在しないときでさえ、transitionsは全ての更新を緊急として扱うよりもよいUXを提供する。
<h2>どこで使えるのか？</h2>
<code>startTransition</code>は更新をバックグラウンドにしたいどのような更新でもラップすることで使用できる。典型的にはこれら更新のタイプを二つのカテゴリに分類することができる。
<ul>
<li>遅いレンダリング（Slow rendering）：これらの更新はReactが結果を表示するためUIを遷移するのに多くの処理を行う必要があるため時間がかかる。</li>
<li>遅いネットワーク（Slow network）これらの更新はReactがデータをネットワークから所得するのを待つのに時間がかかる。このuse caseはSuspenceと強く結びついている。</li>
</ul>

startTransitionを理解する