Clause de non-responsabilité
Cher lecteur! Si vous n'avez aucune idée de ce que sont React et Redux, lire plus n'a pas de sens, c'est un non-sens technique supplémentaire. Sérieusement, comprendre à quoi sert cette note, nécessite de travailler avec ces bibliothèques - malgré le fait que j'essaierai d'écrire clairement, cet article n'est pas d'entrée de gamme. Et c'est une expérience personnelle et une opinion basée sur la pratique.
Quel est le problème avec Redux?
J'ai alors décidé d'écrire, mais qu'est-ce qui ne va pas avec l'utilisation de redux dans mon projet et des milliers d'autres? Je rédige des applications react / redux depuis avril 2016 (trois ans). Il est temps de découvrir déjà des choses intéressantes ... Et puis il y a eu des conférences et des reportages, spécialement destinés aux débutants, mais il n'y a pas eu de retour en arrière des adultes et pas de rétrospective. En attendant, quelqu'un met des astérisques dans des paquets qui cochent "N'êtes-vous pas 13 heures", je briserai le mur des stéréotypes dominants.
Mais redux n'est pas nécessaire!
Vous dites, et à certains égards, vous aurez raison. Vous ne pouvez pas l'utiliser depuis 2018 - il y a une tonne d'articles sur ce sujet sur Internet, mais jusqu'à présent avec la «non-utilisation» vous obtenez une ferme collective, il deviendra clair ci-dessous pourquoi. Et le nombre d'alternatives est hors échelle et encore plus.
Nous utilisons Redux, car c'est une norme acceptée (au moins pour réagir), la prévisibilité et la fiabilité de Redux sont importantes pour nous. Mais cela nous manque sérieusement, en fait dans ce
Réclamation
Probablement, pour clarifier ce qu'est la revendication sur les points, vous devez d'abord revenir au passé, aux racines, comme vous le souhaitez, à savoir ouvrir la documentation du glorieux redux et lire les postulats. Je ne considérerai que le premier d'entre eux. Si cela vous intéresse - partagez les commentaires, j'analyserai bien d'autres points.
La seule source de vérité ...
Ici, nous avons une embuscade. Bien sûr, il dit qu'il peut y avoir 1 étage, redux déclare ainsi sa différence avec l'architecture de flux. Mais si vous regardez plus largement: la règle est-elle observée dans un vrai projet? Vous direz: tout à fait. Je déclare (déclare) 1 côté, je le transfère au fournisseur puis ...
Techniquement, le processus est décrit correctement. Mais je peux dire que les gens sont soumis à des distorsions de perception, de logique, et puisque les programmeurs sont toujours des gens ... Eh bien, vous comprenez à quoi je mène (si vous ne comprenez pas: les programmeurs sont sujets à des distorsions de perception, de logique, etc.)
La principale distorsion ici est que, comme beaucoup de mes collègues, je suis habitué au fait que si nous n'utilisons pas le terme «stocker» par rapport à autre chose que redux, il n'y en a pas d'autre.
Et voici la réaction
Une caractéristique technique appelée état interne voulait cracher sur ce postulat. Il crée simplement une mémoire de type état interne dans n'importe quel endroit pratique. Il y a un composant - il y a un état qui a un mécanisme pour mettre à jour et influencer le composant. La différence d'utilisation (état du magasin, modifications de mise à jour et de diffusion) est presque invisible. Vous pouvez vous opposer: il n'est pas tout à fait clair pourquoi vous n'aimez pas l'état du composant. Il n'est pas comme les éditeurs, comment peuvent-ils même être comparés! C'est interne, eh bien, quels drapeaux y stocker.
Comprenez que l'essence ne change pas du fait que vous renommez l'élément. Il y a un marteau lundi, cela ne fait pas le jour de la semaine. Oui, les deux lundis sont durs, les autres jours et les marteaux sont plus faciles. Mais de par son nom, le marteau ne cesse pas d'être un instrument à percussion.
L'échelle du composant de réaction de redux et d'état est différente, mais l'essence, lorsqu'elle est utilisée aujourd'hui, en est une.
Je vais l'expliquer de cette façon: dans la plupart des cas, les données de l'état interne du composant sont transmises à l'enfant via des accessoires, mais, quelle que soit leur évidence, les données redux, lorsqu'elles sont intégrées à react, pénètrent également dans les composants via des accessoires. Du point de vue du composant qui accepte les accessoires, peu importe ce qui se trouve à l'extérieur. Autrement dit, pour l'utilisateur final - ce magasin redux, cet état interne - est le même.
En outre, cet état interne peut ne pas dépendre des accessoires du composant dans lequel il est déclaré. Ensuite, nous obtenons un isolement qui fait d'un tel état interne un magasin encore plus grand que vous ne l'imaginez.
Pour qu'il soit vraiment interne, il ne doit affecter le composant que là où il est déclaré, sans provoquer de fuites sur les composants enfants. Est-ce difficile? Tout à fait, parce que sa signification est presque complètement perdue. C'est un autre signe que l'état interne est un magasin. Après tout, nous avons simplement supprimé un point de l'objectif de «stocker l'état, mettre à jour et diffuser les changements» - diffuser les changements. Tout, l'Etat est perdu.
Autrement dit, le principal problème avec un état interne est qu'il est en concurrence avec redux pour les données, perd à long terme et merde. Nous avons toutes sortes de techniques telles que la levée de l'état (c'est lorsque le frère de l'élément hôte est nécessaire, donc la partie état et toute la logique de travail avec celle-ci sont transmises au parent, passant beaucoup de temps à réécrire et tester la logique de travail), etc. Des bogues apparaissent, des frais généraux dans les améliorations et beaucoup de joie. C'est tout le bruit qui gâche notre logiciel au stade du développement. Nous n'avons pas atteint les ventes, mais le logiciel est déjà comme ça.
Autrement dit, pour tous les signes et problèmes, nous avons plus d'une histoire et de nombreux problèmes associés à cela. La dernière chose, probablement, sera la suivante:
J'adore aussi redux pour le type d'outils de développement qu'il possède. Lorsque j'ai commencé, nous avons utilisé un enregistreur qui a simplement consolidé toutes les actions, sans toutefois donner une image complète de ce qui se passait. Maintenant - c'est l'assistant principal et l'ami. Chez React, ils sont également représentés. En général, devtools est la raison pour laquelle n'importe quel pub est loin de Redux. Comme une fourmi à une baleine bleue.
Problèmes (il n'y aura pas de preuves ADN):
- changer l'état interne via react devtools ne conduit parfois pas à une mise à jour ou au résultat souhaité - je pèche sur l'intégration avec redux.
- l'état interne rompt le voyage dans les devtools redux. La super fonctionnalité avec le voyage dans le temps disponible via l'architecture redux ne fonctionne pas grâce à l'architecture d'état interne réactif. L'état interne ne se souciait tout simplement pas d'un changement de redux, il a son propre état. Timetravel ne fonctionne tout simplement pas. Certains éléments ne sont tout simplement pas mis à jour, partiellement mis à jour, etc. Toute cette épopée avec une synchronisation de code asynchrone en aval.
Un exemple, bien sûr, aspiré par la pratique
Vous travaillez sur un nouveau projet pour vous, ou votre collègue a écrit une fonctionnalité il y a un an, et vous devez maintenant l'étendre. En général, il y a la tâche de finaliser le code de quelqu'un d'autre. Vous commencez à enquêter et comprenez qu'il n'y a pas de données dans les éditeurs. Il n'y a aucune action, réducteur dans le code qui stocke les données dont vous avez besoin. Et vous commencez le voyage à travers l'arbre des composants à la recherche des trésors et trouvez-les (!!!) même quelques pièces. Vous demandez à mes collègues, mais la réponse est standard: je ne me souviens pas avoir écrit à l'État plus rapidement, nous n'avions pas le temps, etc. Vous allez à la source et comprenez que son état actuel n'implique pas de révision. Vous réécrivez du code testé et fonctionnel pour apporter des modifications et ajouter de nouvelles fonctionnalités.
La présence d'une alternative pernicieuse sous la forme d'un état interne fait son sale boulot. Après tout, maintenant c'est bon marché, et peu importe ce qui se passe dans un an.Peu de métaphores
Il ressemble à de la mauvaise nourriture - il semble savoureux et bon marché, mais après un an ou trois - le tractus gastro-intestinal cesse d'obéir et vit sa propre vie. Vous dépensez beaucoup de temps et d'argent pour retrouver votre ancienne santé et n'y réussissez pas toujours.
Redux et React Internal State sont des concurrents , en tant que grandes et petites entreprises dans un créneau. Le produit principal est les données et l'influence. Le logiciel est le consommateur de leurs produits. Il existe de nombreuses analogies, mais l'essence reste la même - lorsque nous développons des logiciels - nous n'avons pas besoin de concurrence.
Nous sommes les «dictateurs» du code du programme et toute concurrence doit être supprimée, le marché libre doit être interdit et l'économie planifiée et le monopole d'État doivent dominer le consommateur.Ahem, quelque chose m'ennuyait. Tout devrait se dérouler comme prévu, en général. Nous avons des sprints, des versions et plus encore, et le logiciel a un coût fini et une durée de vie / entrée sur le marché. C'est très important, et nous ne pouvons pas permettre l'émeute sur le navire, le soulèvement des bibliothèques.
La conclusion est simple.
N'utilisez pas d'autres référentiels avec redux. Les exceptions ne peuvent faire que des cas très isolés. Par exemple, les composants qui en principe ne sont pas contrôlés par redux sans la couche correspondante et ne l'affectent pas.
Exemple
J'ai développé le module autonome dans une branche et refactorisé le magasin dans une autre - en général, mon approche de la gestion du magasin et de l'état est un sujet distinct pour la publication. J'ai commencé à refactoriser le module, mais au moment du début et de la fin de l'écriture du module, le refactoring au test et à l'assistant ne s'est pas arrêté. Le refactoring est important et nécessite un recours réfléchi qui doit être planifié - en général, vous ne pouvez pas simplement prendre et refactoriser.
Par conséquent, connaissant les changements à venir dans le magasin, je ne l'ai pas utilisé pour développer une nouvelle fonctionnalité. Cela augmenterait parfois les coûts de mise à jour du refactoring et des tests abandonnés.
Ce que j'ai fait: je me suis inscrit pour un minimum de données. Les données et leur structure n'ont pas souffert de refactorisation, le code qui les a générées a souffert, enregistré, etc. Je n'ai pas écrit d'octet aux éditeurs. Je vérifie si l'utilisateur est connecté et quelques champs supplémentaires.
Pour mes besoins, j'ai lavé PubSub avec des canaux et une API simple. Oui, oui, pubsab. Absence de douleur douloureuse normale. Voyage dans le temps - Douleur. En général, je prévois d'écrire une extension pour Chrome sous la forme de devtools et il est possible de publier une réimplémentation en tant que concurrent pour redux sur le github. J'ai une tonne de plaintes concernant redux, que je ne soulèverai pas dans cet article, mais PubSub ne les a pratiquement pas. Outre le fait que je me souvenais de l'enregistreur redux ...
Et donc le module a son propre stockage, sa propre connexion au serveur.
Autrement dit, redux n'affecte pas du tout le module, ne peut pratiquement pas affecter ce stockage (il n'y a que trois champs dans l'abonnement), mais le module et PubSub n'affectent en rien redux. Cette séparation exclut la concurrence.
La question "où stocker les données?" lors du développement du module, je ne l'ai jamais rencontré. Mais quand il s'agit de redux vs état interne - pour beaucoup, cette question se pose presque constamment. J'ai décidé de répondre une fois pour toutes à cette question.
Mon opinion architecturale est:
Stockez les données uniquement dans redux (global, même «interne»), si elles sont connectées à votre projet React en tant que référentiel principal, n'utilisez pas de référentiels qui lui feront concurrence. Cela augmentera la fiabilité et l'impact de cette bibliothèque et de ses outils de développement (le suivi temporel et le suivi de toutes les données par étapes accélèrent le développement et la recherche d'éventuels problèmes - les changements synchrones sont plus raides et plus faciles à asynchrones).
Peut-être qu'il vaut la peine d'ajouter une bibliothèque qui exclut complètement l'état interne du développement? Ou remplace l'état interne par une sélection de redux, par exemple? J'ai commencé à en écrire un il y a un an, j'ai terminé à 90% et j'ai même réalisé 1 rapport. Que dites-vous? Vous en avez besoin?
J'espère que vous avez apprécié cette note :)