La description du projet Redux est:
Redux est un conteneur d'état prévisible
Pouvez-vous m'expliquer ce que signifie le mot "prévisible" dans ce contexte?
3 Réponses :
Vous devez d'abord comprendre le fonctionnement de Redux. Il existe quelques principes clés:
(state, action) => state ) Vous pouvez donc voir que tout cela est unidirectionnel (les changements ne se font que dans un seul sens):
état -> action -> réducteur -> état -> action -> réducteur -> état ...
Redux est fortement inspiré de l'architecture Elm et encourage les principes de programmation fonctionnelle, l'un d'entre eux étant des fonctions pures (ils ne produisent aucun effet secondaire (comme les appels http, les lectures de disque) et leur sortie est toujours la même pour la même entrée).
/ p>
Chaque changement d'état des réducteurs doit être pris en charge explicitement par les développeurs. De plus, tous les réducteurs sont censés être purs. C'est de là que vient la prévisibilité.
Donc, pour résumer, prévisible dans ce contexte signifie qu'en utilisant Redux, vous saurez ce que chaque action de l'application fera et comment l'état changera.
Je pense que le fait que, compte tenu d'un flux d'actions, vous vous retrouvez toujours dans le même état, il convient également de le mentionner
@francium n'hésitez pas à mettre à jour ma réponse! OP semblait nouveau dans ce concept, donc je ne voulais pas le surcharger :)
C'est peu de confusion. Je suppose que chaque machine «john von neumann» remplit un état prévisible. Je comprends, entendez cela se produire selon un schéma bien connu. Merci.
Je suggérerais de l'essayer d'abord. Vous comprendrez bientôt pourquoi c'est prévisible. 👌
Je ne sais pas encore comment ça marche. disons que nous allons faire Skype comme un projet. Les gros messages de discussion défilés. Ainsi, chaque action, comme supprimer ou recevoir ou même faire défiler plus profondément vers l'année dernière, c'est dupliquer la liste afin de remplir la règle immuable et de la rendre capable de l'annuler?
C'est correct. Mais encore une fois, ce que vous avez décrit peut être mis en œuvre de nombreuses manières, certaines étant performantes et d'autres non. Par exemple, Slack utilise redux si vous vous souciez des performances.
Désolé pour mon erreur ci-dessus. Au lieu de cela, «john von neumann» devrait être «Alan Turing».
Après un certain temps, j'ai compris le point: Tout d'abord, ma question vient de C ++ / Java / C # événementiel (Redux a une implémentation non seulement pour JS).
Alors je me demande ce qui est si mauvais avec un environnement de pilotage événementiel à l'ancienne comme Winform et autres? Ils fonctionnent tous avec DataTable ou une collection de classes simples (Structures). Le composant visuel conserve l'état d'édition ou d'un autre état de widget, mais pas du tout de logique. (Je ne me réfère pas ici à de grands mots comme MVC ou MVVW ou tout autre slogan. Mais tous convainquent la même vérité: nous devons séparer la vue de Logic dans certains manière ).
Reportez-vous à la réponse Evaldas Buinauskas , ayez 4 principes. Laissez-moi vous expliquer pourquoi ces principes ne sont pas les pionniers:
1> Pour quelle raison ai-je besoin d'immuable? (La prise de conscience de changement automatique peut être faite avec la programmation orientée aspect ou même n'est pas si mal appeler le re-rendu manuellement après chaque action)
2> Idem ci-dessus (je suppose toujours que nous ne voulons pas de stockage de trous de clonage pour chaque action sans supprimer la précédente. Pour la plupart des applications, ce n'est pas nécessaire ou impossible en raison du manque de RAM).
4> Certains des éléments ci-dessus. Immuable non nécessaire et nouvel état en raison de la mise en œuvre de l'action correctement avec tous les modèles de pilote d'événement connus.
Donc, je pense que la réponse principale de Evaldas Buinauskas de mon point de vue est:
Redux est fortement inspiré de l'architecture Elm et encourage les principes de programmation fonctionnelle, l'un d'entre eux étant des fonctions pures (ils ne produisent aucun effet secondaire (comme les appels http, les lectures de disque) et leur sortie est toujours la même pour la même entrée).
/ p>
Avec une fonction pure qui ne change rien en dehors de Store, nous obtenons un code plus clair et testable (je suppose que cela signifie des mots "Prédicat").
Redux est un "conteneur d'état" car il contient tout l'état de votre application. Il ne vous permet pas de changer cet état directement, mais vous oblige à la place à décrire les changements comme des objets simples appelés «actions». Les actions peuvent être enregistrées et rejouées plus tard, ce qui rend la gestion de l'état prévisible. Avec les mêmes actions dans le même ordre, vous allez vous retrouver dans le même état.
Par Dan Abramov
hashnode. com / post /… : réponse de l'auteur