Consommation de mémoire Redux
Le cadre Redux favorise le paradigme immuable état/fonction pure, qui favorise la création d'un nouvel état à partir de l'état précédent en termes d'action en cours. L'applicabilité de ce paradigme est indubitable.
Une de mes préoccupations majeures est que, comme les réducteurs Redux renvoient avec impatience de nouveaux états des états précédents pour chaque action invoquée, le drain de mémoire massif (à ne pas confondre avec les fuites de mémoire) deviendrait un phénomène courant dans de nombreuses applications du monde réel. . Lorsque l'on considère que les applications Javascript s'exécutent normalement dans un navigateur sur les appareils d'un utilisateur moyen qui pourraient également exécuter plusieurs autres applications spécifiques à l'appareil et plusieurs autres onglets et fenêtres de navigateur, la nécessité de conserver la mémoire devient de plus en plus évidente.
Quelqu'un a-t-il réellement comparé la consommation de mémoire d'une application Redux à l'architecture Flux traditionnelle? Si oui, pourraient-ils partager leurs conclusions?
C'est une préoccupation valable. Bien que je n'aie pas mesuré l'utilisation de la mémoire des applications Redux, je pense qu'avant de vous engager à utiliser Redux (ou tout autre framework d'ailleurs), vous devez créer des tests de stress qui émulent les quantités de données, modifient la fréquence et l'intensité de calcul de l'application que vous vont construire. Utilisez ces tests de résistance avant de prendre des décisions technologiques pour savoir si l'adoption de l'immuabilité fonctionne dans votre cas particulier.
Notez que parfois les gens sont confus à propos de Redux et supposent qu'à chaque action, l'arbre d'état doit être cloné profondément. Ce n'est absolument pas le cas. Seules les pièces qui ont changé doivent changer leurs références. Par exemple, si une action entraîne une modification d'un élément dans un tableau, en effet, cet élément et le tableau devront être copiés, cependant, tous les autres éléments du tableau conserveront leur identité. Parce que la plupart du temps, les actions sont très ciblées et affectent quelques clés d'état, et parce que Redux encourage la normalisation des données afin que les structures de données ne soient pas profondément imbriquées, cela pose beaucoup moins de problèmes pour les applications Web typiques qu'on pourrait l'imaginer.
Vous souhaiterez également explorer l'utilisation de bibliothèques comme Immutable.js qui implémentent efficacement des listes et des cartes immuables en utilisant le partage structurel en interne. De cette façon, la modification de quelques éléments dans une liste n'implique pas autant de copie, car en interne, la majeure partie de la mémoire est partagée entre différentes versions de la structure de données.
Mais à la fin, la seule façon de le dire est d'écrire les tests de résistance qui imitent étroitement l'utilisation prévue de votre application et de mesurer l'efficacité par vous-même.