【ITニュース解説】I mounted 1,000 rows that each read one item from a store, changed one item, and counted renders in React 19. Read the art: https://mozzammel-haque.medium.com/i-changed-one-of-1-000-items-in-zustand-redux-toolkit-and-jotai-on-react-19-cc3dceb94846?sharedUs
2026年11月02日に「Dev.to」が公開したITニュース「I mounted 1,000 rows that each read one item from a store, changed one item, and counted renders in React 19. Read the art: https://mozzammel-haque.medium.com/i-changed-one-of-1-000-items-in-zustand-redux-toolkit-and-jotai-on-react-19-cc3dceb94846?sharedUs」について初心者にもわかりやすく解説しています。
ITニュース概要
React 19環境で、ZustandやRedux Toolkitなど複数の状態管理ライブラリを使用。1000個のデータを持つリストを作成し、そのうち1つのデータを変更した際に、画面が何回更新されたかを計測。各ライブラリのパフォーマンスを比較検証した。
ITニュース解説
Reactは現代のWebアプリケーション開発で広く使われる技術であり、ユーザーインターフェースを効率的に構築するための強力なツールである。その性能を最大限に引き出すためには、データの管理、つまり「状態管理」を適切に行うことが非常に重要になる。特に、画面に表示される要素(コンポーネント)が大量にある場合や、データが頻繁に更新される場合、不適切な状態管理はアプリケーションの動作を遅くする原因となる。この記事では、そのような状況でReact 19の動作と、主要な状態管理ライブラリの効率性を検証している。
Reactアプリケーションは、UIの部品である「コンポーネント」の集合体で構成される。これらのコンポーネントはそれぞれが独自の「状態(State)」を持つことができるが、複数のコンポーネントで共有するような大規模なデータは、通常「状態管理ライブラリ」が提供する「ストア」と呼ばれる一箇所にまとめて管理される。ストアはアプリケーション全体の共有データを保持する場所であり、各コンポーネントはこのストアから必要なデータを読み込む。そして、ストア内のデータが更新されると、そのデータを使っているコンポーネントは画面を最新の状態に更新するため、再度描画される。この動作を「再レンダリング」と呼ぶ。
理想的には、データが変更されたときに、そのデータに直接関連するコンポーネントだけが再レンダリングされるべきである。しかし、状態管理の方法によっては、関係のないコンポーネントまで不必要に再レンダリングされてしまうことがある。これが多すぎると、アプリケーションは無駄な処理を繰り返し、動作が重くなる。だからこそ、不要な再レンダリングをいかに減らすかが、Reactアプリケーションのパフォーマンス最適化において重要な課題となる。
今回の検証では、この「不要な再レンダリング」がどれだけ発生するかを測るために、非常に具体的なシナリオが設定されている。それは、1000個の独立した行コンポーネントが存在し、それぞれの行がストアから異なる1つのアイテムデータを読み込んでいる状況だ。この1000個のアイテムの中から、たった1つのアイテムのデータだけを変更したときに、実際にいくつの行コンポーネントが再レンダリングされたかを計測している。このシナリオは、例えばECサイトの商品リストやSNSのタイムラインのように、大量のデータ項目が並び、その中の一部だけが更新されるような、現実のWebアプリケーションで非常によくあるパターンを模している。このような状況で効率的な再レンダリングを実現できるかどうかは、アプリケーションのユーザー体験に直結する。
検証に使われた状態管理ライブラリは、「Zustand」「Redux Toolkit」「Jotai」の三つである。これらはそれぞれ異なる設計思想と特徴を持っている。Zustandは、軽量でシンプルなAPIが特徴で、手軽に状態管理を始めたい場合によく選択される。Redux Toolkitは、Reduxという歴史ある状態管理ライブラリの推奨実装であり、大規模なアプリケーションで堅牢な状態管理を行うための豊富な機能と厳密な規約を提供する。Jotaiは、Recoilと同様に「アトム」という概念を基盤とした状態管理ライブラリで、各データ項目を独立したアトムとして扱い、変更があったアトムだけを効率的に追跡して関連コンポーネントを更新することを目指している。
検証の結果は、それぞれのライブラリが再レンダリングをどれだけ効率的に抑制できるかに明確な差があることを示している。理想的には、1000個のアイテムのうち1つだけを変更したのだから、再レンダリングされるコンポーネントも、その変更されたアイテムを表示する1つだけの行コンポーネントであるべきだ。検証結果として、ZustandとJotaiが、この理想に近い少ない再レンダリング回数を達成していることがわかる。これは、これらのライブラリが内部的に、変更されたデータとその影響範囲を賢く特定し、関係のないコンポーネントへの再レンダリングを避けるような仕組みを持っているためである。特にJotaiのようなアトムベースのライブラリは、個々のデータを独立した単位(アトム)として扱うことで、きめ細やかな更新を可能にする。
一方、Redux Toolkitでは、特定の工夫をしないと、変更されたアイテム以外のコンポーネントまで不必要に再レンダリングされてしまう傾向が見られる。Redux Toolkitは高機能である反面、ストアの構造やデータの読み込み方(セレクターの使用など)を適切に設計しないと、広範囲にわたる再レンダリングを引き起こしやすい場合がある。これは、Reduxがストア全体が一度に更新されるというモデルを基本としているため、部分的な変更を効率的に扱うには開発者による意識的な最適化が求められることを示唆している。React 19は、内部的な最適化や新しいAPIを提供しているが、今回の検証結果からは、状態管理ライブラリの選択や実装方法が、再レンダリングの効率に与える影響が依然として大きいことが読み取れる。
この検証結果は、システムエンジニアを目指す初心者にとって非常に重要な示唆を与えている。それは、Reactアプリケーションのパフォーマンスは、単にコードを書くだけでなく、適切なツールを選択し、そのツールが提供する機能を理解し、賢く利用することで大きく改善されるという点である。特に、データ量が多く、頻繁に更新されるようなアプリケーションを開発する際には、状態管理ライブラリの選定がアプリケーション全体の性能に直接影響することを理解しておく必要がある。そして、選んだライブラリの特性に合わせて、データの構造化やコンポーネントからのデータの読み込み方を最適化する知識と技術が求められる。不必要な再レンダリングは、ユーザー体験を損なうだけでなく、アプリケーションの複雑性を増し、デバッグを困難にする可能性もある。この検証は、パフォーマンス改善のための意識と、状態管理の深い理解がいかに重要であるかを教えてくれる貴重な情報源と言えるだろう。