Quand ne pas utiliser Redux dans React-Native?
J'ai récemment commencé à travailler sur les applications React-Native et j'ai trouvé Redux utile. Mais selon ma compréhension, lorsque j'utilise Reducers (principalement pour utiliser des API WebServices), les données sont stockées dans un état au niveau de l'application qui pourrait être utilisé par Components. Ne serait-il pas sévère pour la performance de l'application, car toutes les données seraient à l'état au niveau de l'application? Je suis confus ici. S'il vous plaît recommander un moyen de sortir. Merci
Redux single store ne devrait pas affecter les performances de vos applications. La seule différence est que tous vos objets d'état sont imbriqués dans une seule arborescence, plutôt que stockés dans plusieurs composants différents et imbriqués.
Au lieu de cela, ce qui affecte vraiment les performances des applications React, c'est le processus de rendu. Dans React, la mise à jour continue d'un état ou de composants locaux du composant peut entraîner une baisse des performances en raison d'un re-rendu conséquent, parfois inutile. Si vous êtes vraiment préoccupé par les performances de Redux, cet article pourrait couvrir la plupart de vos doutes et vous donner des informations utiles.
Oui, les données seront dans un état global. C'est l'idée même. Pour partager des données entre deux composants, nous devons passer de l’état au composant parent commun. Pour une application complexe, cela causera toujours des problèmes de flux de données. Redux résout les problèmes de flux de données en passant de l'état à un conteneur d'état global. Depuis le magasin redux, l'état se transmet à tous les composants via les accessoires. Cela encourage les flux de données unidirectionnels dans les applications React. Toute modification d'état est apportée au magasin Redux via des actions envoyées. Et à partir de l'état global, les données circulent vers les composants de conteneur et de présentation.
Les performances des applications ne sont généralement pas un problème. J'ai connu des personnes utilisant plus de 100 réducteurs et la performance est bonne. Pour les formulaires, il est préférable d’avoir un état local pour TextInput. Et utilisez onBlur pour enregistrer l’état sur Redux Store.
Quand ne pas utiliser Redux? Pour les applications simples ne comportant que quelques écrans, Redux peut s'avérer excessif. Pour les applications simples, tout ce que vous avez à faire est d’avoir tout l’état dans le composant racine ou les composants de conteneur et de le laisser se dérouler jusqu'aux composants de présentation. Si vous connaissez Redux, vous pouvez toujours utiliser Redux. Aucun mal n'est fait. Mais facile à utiliser l'état local pour des applications plus simples.
Comme je le vois (seulement mon avis):
- Redux/Flux/Programmation fonctionnelle
- Une logique plus défragmentée (magasin, actions, réducteur, vue, contrôleur de vue, middlewares). Plus difficile de réutiliser des parties de l'application (il faudra copier et éditer un grand nombre de fichiers de code source)
- "Boîte blanche" logique. Flux d'exécution unidirectionnel, d'excellents outils pour tester les actions, les états et les problèmes de réplication
- Plus difficile à gérer le multi-threading, mais toujours possible. Besoin d'utiliser des actions fonctionnelles.
- Plus de logique exécutée sur le client (une des raisons pour lesquelles Facebook l'a développée)
- Bien adapté aux applications d'interface utilisateur volumineuses ou collaboratives
- MVC/OOP
- Une logique plus unie (modèle, vue, contrôleur). Beaucoup plus facile de réutiliser des parties de l'application.
- "Boîte noire" logique. Le déroulement de l'exécution n'est pas contrôlé. Pourrait se retrouver dans des impasses, des boucles infinies, difficile à reproduire des états et des problèmes.
- Plus facile à gérer le multi-threading.
- Plus de logique exécutée sur le serveur
- Structure bien adaptée aux applications d'interface utilisateur petites ou réutilisables
En ce qui concerne les applications non-UI: OOP est beaucoup plus approprié pour créer des bibliothèques ou des applications réutilisables non-UI sans nature transactionnelle/événement. Actuellement, presque toutes les bibliothèques d'applications non-UI sont toujours construites en POO. Il serait difficile de combiner ces deux mondes. Peut-être qu'à l'avenir, tout changera, mais pour l'instant, je ne recommanderais pas d'utiliser Redux/Flux pour des applications non-UI.