流暢なReact

第7章. コンカレントReact

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

前章では、Reactを使ったサーバ側レンダリングの世界を深く掘り下げた。特に最新のウェブ開発において、アプリケーションのパフォーマンスとユーザ体験を向上させるためのサーバ側レンダリングの重要性を検証した。renderToString やrenderToPipeableStream など、さまざまなサーバ・レンダリングAPIについて調べ、その使用例と利点について議論した。また、サーバ側レンダリングを実装する上での課題や、複雑な処理をNext.jsやRemixのような確立されたフレームワークに依存することがいかに優れているかについても触れた。

我々はハイドレーションの概念と、サーバ側でレンダリングされたマークアップとクライアント側Reactコンポーネントを接続し、シームレスなユーザ体験を作成する上でのその意義について説明した。さらに、サーバフルな環境で複数のクライアント接続を管理する際に生じる潜在的なセキュリティ上の問題や課題について議論し、これらの懸念を効果的に処理するフレームワークを使用する必要性を強調した。

さて、次のReactの並行処理に移るにあたり、これまで学んできたことの理解をさらに深めていく。Fiberリコンサイルに飛び込み、Reactの並行機能、そして更新とレンダリングの効率的な管理方法について学ぶ。スケジューリング、更新の遅延、レンダーレーンを検証することで、Reactのコアアーキテクチャが可能にするパフォーマンスの最適化について理解を深める。

注

繰り返しになるが、Fiberそのものやこれから説明することは、Reactの実装の詳細であり、今後変更される可能性が高く、Reactを効果的に使うために知っておく必要はない。 しかし、その根底にある仕組みを学ぶことで、Reactの仕組みや効果的な使い方をより深く理解できるようになり、また一般的なエンジニアとしての知識も深まるだろう。

私たちは専門知識を蓄積し、高性能アプリケーションの作成にReactのパワーを活用する新しい方法を発見し続けている。

同期レンダリングの問題点

要約すると、同期レンダリング（ ）の問題点は、メインスレッドがブロックされ、ユーザ体験が低下することである。これは、コンポーネントが多く、頻繁に更新される複雑なアプリケーションに特に当てはまる。このような場合、UIが応答しなくなり、イライラするユーザ体験になる可能性がある。

この問題に対する典型的な緩和策は、 、一連のアップデートをバッチ処理して1つのアップデートにまとめ、メインスレッドで行われる作業を最小限に抑えることである。10個のアップデートを10回処理する代わりに、バッチ処理して1回で済ませるのだ。バッチ処理については第4章で取り上げたので、ここではこれ以上詳しく説明しないが、今回の議論では、バッチ処理がこのような問題の緩和策であることを理解することが重要である。

これまで話してきたような問題は、バッチングを使った場合であっても、設計上、同期レンダリングには優先順位がないという事実によってさらに複雑化する。可視性にかかわらず、すべての更新を平等に扱う。たとえば、同期レンダリングでは、表示されていないタブ、モーダルの背後にあるコンテンツ、ローディング状態のコンテンツなど、ユーザが見ることができないアイテムのレンダリング作業でメイン スレッドをブロックすることができる。CPUに余裕があれば、それらのアイテムもレンダリングしたいが、ユーザが見て対話できるものを優先的にレンダリングしたい。Reactに同時実行機能が搭載される前は、重要な更新がそれほど重要でない更新によってブロックされ、ユーザ体験が損なわれるという状況がしばしば発生していた。 ...