Reduxのメモリ消費[終了]

Reduxフレームワークは、不変の状態/純粋関数パラダイムを支持します。これは、現在のアクションに関して、前の状態から新しい状態の作成を促進します。このパラダイムの適用可能性は疑う余地がありません。

私の主な懸念は、Reduxレデューサーが呼び出されたアクションごとに以前の状態から新しい新しい状態を熱心に返すため、大量のメモリドレイン（メモリリークと混同しないでください）が多くの実際のアプリケーションで一般的に発生することです。Javascriptアプリケーションは通常、平均的なユーザーのデバイスのブラウザーで実行され、他のいくつかのデバイス固有のアプリケーションと、さらにいくつかのブラウザーのタブとウィンドウも実行できることを考慮すると、メモリを節約する必要性がますます明らかになります。

Reduxアプリケーションのメモリ消費量を従来のFluxアーキテクチャと実際に比較した人はいますか？もしそうなら、彼らは彼らの調査結果を共有できますか？

これは有効な懸念事項です。Reduxアプリケーションのメモリ使用量を測定していませんが、Redux（またはその他のフレームワーク）の使用をコミットする前に、アプリケーションのデータ量、変更頻度、計算強度をエミュレートするストレステストを作成する必要があると思います構築する予定です。特定のケースで不変性を採用するかどうかについて技術的な決定を行う前に、これらのストレステストを使用してください。

Reduxについて混乱する場合があり、すべてのアクションで状態ツリーのクローンを深く作成する必要があると想定する場合があることに注意してください。これは絶対に当てはまりません。変更された部分のみが参照を変更する必要があります。アクションは、アレイ内の1つのアイテムに変化を引き起こした場合、確かに、その項目及び配列は、コピーする必要があります。ただし、アレイ内のすべての他の要素が自分のアイデンティティを維持します。ほとんどの場合、アクションは非常にターゲットが絞られており、いくつかの状態キーに影響を及ぼします。また、Reduxはデータ構造が深くネストされないようにデータを正規化することを推奨しているため、これは一般的なWebアプリでは想像されるほど問題ではありません。

また、内部で構造共有を使用して、不変のリストとマップを効率的に実装するImmutable.jsのようなライブラリーを使用して探索することもできます。このように、リスト内のいくつかのアイテムを変更することは、内部的にほとんどのメモリがデータ構造の異なるバージョン間で共有されているため、それほど多くのコピーを必要としません。

しかし、結局のところ、伝える唯一の方法は、アプリの使用目的を厳密にエミュレートするストレステストを記述し、自分で効率を測定することです。