11
votes

Mettre à jour l'état Redux sur le changement de route

J'essaye de comprendre cela pendant un moment et que je deviens de plus en plus confus.

Je veux réinitialiser / modifier Redux State à chaque fois que je quitte ou change d'itinéraire. J'utilise réacteur-routeur-redux avec historique.listener expédiant une action chaque fois modifications de route xxx


< p> Créateur d'action: xxx

réducteur xxx

Qu'est-ce qui me confond le plus, l'État met à jour si je Actualisez la page ou cliquez deux fois sur l'itinéraire dans la NAV TOP, mais une modification unique n'affecte pas l'état Redux, même si l'action et le réducteur incendie (affiche le message de test dans la console).

Qu'est-ce que je fais mal et ce qui se passe réellement ici?


0 commentaires

3 Réponses :


22
votes

réact-routeur-redux fournit une action emplacement_change , qui est déjà expédiée sur chaque changement de route. Vous pouvez faire simple: xxx


5 commentaires

est emplacement_change identique que @@ routeur / emplacement_changer ?


Oui. Vous pouvez également utiliser '@@ routeur / emplacement_change', mais ce n'est pas recommandé.


Je viens de réaliser ce qui cause le problème et il est légèrement différent de cette question. Peut-être que vous pourriez aider? Stackoverflow.com/questions/37912180/...


Est-ce que cela s'applique également si vous souhaitez réinitialiser l'état d'un itinéraire spécifique uniquement?


Cette réponse ne fonctionne plus. React-Router-Redux a été renommé au routeur de réacteur connecté et ne semble plus que cela fonctionne de la même manière.



8
votes

J'ai utilisé une approche différente pour réinitialiser l'état lors de la modification des itinéraires. Au lieu d'écouter l'histoire / le routeur, j'ai utilisé composantwillmount sur mes conteneurs de page pour envoyer une action "Réinitialiser". Exemple:

routeur: xxx

Page1 conteneur: xxx

réducteur: xxx


MISE À JOUR : Comme @DavidHarkness mentionné, la faille de cette approche est que le composant rendu deux fois sur le montage. Et en dehors de cela, j'ai maintenant tendance à penser que cette solution n'est pas élégante et il est préférable d'éviter d'utiliser la logique de Bustsiness à l'intérieur des composants. Déplacement de la logique à l'intérieur du réducteur serait une meilleure option (voir @Diegohaz Réponse).


2 commentaires

Cela semble que ce serait une bonne solution si, pour une raison quelconque, vous n'avez besoin que de réinitialiser la partie (s) de l'état utilisé par le composant utilisé.


Cela ne fera-t-il pas de rendre avec l'état précédent puis de repartir immédiatement avec le nouvel État?



3
votes

Actuellement, je fais l'usage de composantwillunmount () pour faire cela . J'ai une configuration d'action dans le réducteur, je souhaite réinitialiser pour réinitialiser son état et j'enregistre l'action de la méthode ComposantwillunMount () .

Un problème que vous pouvez expérimenter est que, lors de l'utilisation du routeur de réact, un changement d'itinéraire ne déclenchera pas un rafraîchissement et un composant ne remontera pas sur le même itinéraire, donc par exemple si vous avez des messages / Nouveau et un message / modifier. /: ID itinéraire à la fois en utilisant le même composant pour éditer un message, vous allez entre ces itinéraires ne fera pas remonter le composant.

À cause de cette ComposantwillunMount () non Eure, le même composant ne sera que de nouveaux accessoires. Par conséquent, vous pouvez utiliser composantwillreceiveProps (NewProps) pour effectuer une comparaison et mettre à jour en conséquence.

Si vous souhaitez forcer le composant à remonter à vous remonter, vous devez vous assurer que le composant que vous souhaitez disposer a un attribut de clé différent, voir ici et Voici pour plus d'informations.


0 commentaires