Reduxのメモリ消費
Reduxフレームワークは、現在のアクションの観点から、以前の状態からの新しい状態の作成を促進する不変の状態/純粋関数パラダイムを支持します。このパラダイムの適用性は間違いありません。
私の主な懸念は、Reduxレデューサーが呼び出されたすべてのアクションに対して以前の状態から新鮮な新しい状態を熱心に返すため、大量のメモリドレイン（メモリリークと混同しないでください）が多くの実際のアプリケーションで一般的に発生することです。 。 JavaScriptアプリケーションは通常、平均的なユーザーのデバイスのブラウザーで実行され、他のいくつかのデバイス固有のアプリケーションといくつかのブラウザーのタブとウィンドウも実行できることを考えると、メモリーを節約する必要性がますます明らかになります。
Reduxアプリケーションのメモリ消費量を従来のFluxアーキテクチャと実際に比較した人はいますか？もしそうなら、彼らは彼らの発見を共有できますか？
これは正当な懸念事項です。 Reduxアプリケーションのメモリ使用量は測定していませんが、Redux（またはそのほかのフレームワーク）を使用する前に、アプリケーションのデータ量、変更頻度、および計算強度をエミュレートするストレステストを作成する必要があると思います。構築する予定です。特定のケースで不変性の採用が機能するかどうかについて技術的な決定を行う前に、これらのストレステストを使用してください。
Reduxについて混乱し、すべてのアクションで状態ツリーを深く複製する必要があると考える人もいることに注意してください。これは絶対にそうではありません。変更されたパーツのみが参照を変更する必要があります。たとえば、アクションによって配列内の1つの項目が変更される場合、実際には、その項目と配列をコピーする必要がありますただし、配列内の他のすべての要素はIDを保持します。ほとんどの場合、アクションは非常にターゲットが絞られていて、いくつかの状態キーに影響を与えます。また、Reduxはデータ構造を深くネストしないようにデータを正規化することを推奨しているため、一般的なWebアプリケーションの問題は想像以上に少ないものです。
また、内部的に構造共有を使用して不変のリストとマップを効率的に実装するImmutable.jsなどのライブラリを使用して探索することもできます。このように、内部でほとんどのメモリがデータ構造の異なるバージョン間で共有されているため、リスト内のいくつかの項目を変更しても、それほど多くのコピーは含まれません。
しかし結局のところ、伝える唯一の方法は、アプリの使用目的を厳密にエミュレートするストレステストを記述し、自分の効率を測定することです。