0

Dans cet exemple de projet, j'ai un formulaire de connexion et j'ai quelques actions qui attendent d'être expédiées en cas de connexion vérifiée ou échec de connexion.Redux: Modification de l'état dans Reducers, est-ce acceptable?

Ces deux actions sont potentiellement déclenchées par une action qui gère l'événement submit qui est en communication avec le backend. Selon la réponse du backend, il se déclenche vérifié connexion ou échec de connexion.

Afin de réagir correctement à ces situations dans la couche de vue, j'ai quelques booléens dans l'état. Le réducteur ci-dessous modifie l'état de ces valeurs en fonction du déclencheur.

Réducteur

import {FAILED_LOGIN, VERIFIED_LOGIN} from './../actions/LoginActions'; 

const INITIAL_STATE = { 
    loginRejected: false, 
    loginApproved: false, 
    username: null, 
    id: null, 
    token: null 
}; 

export default function(state = INITIAL_STATE, action) { 
    switch (action.type) { 
    case FAILED_LOGIN: 
     return { 
      ...state, 
      loginRejected: true 
     }; 
    case VERIFIED_LOGIN: 
     return { 
      ...state, 
      loginRejected: false, 
      loginApproved: true, 
      username: action.payload.data.email, 
      id: action.payload.data._id, 
      token: action.payload.headers['x-auth'] 
     }; 
    default: 
     return state; 
    } 
} 

Est-il considéré comme une mauvaise pratique de muter l'Etat comme celui-ci dans un réducteur? Je sais que je peux renvoyer les valeurs que je suis en train d'éditer dans les actions elles-mêmes et assigner les valeurs retournées dans le réducteur comme je le fais avec les données utilisateur. Considérez-vous cela comme une meilleure pratique par rapport au formulaire actuel?

+0

Où est la mutation d'état? –

+3

Vous ne mutez pas l'état du tout. En fait, c'est un bon exemple de la façon dont les actions et l'état doivent être gérés. Les actions contiennent uniquement les données pertinentes et les réducteurs modifient uniquement les bits qui doivent être modifiés, laissant l'état intact. –

+0

Je pensais que c'était peut-être une meilleure pratique de gérer cela dans les actions elles-mêmes plutôt que le réducteur. Mais il semble qu'il n'y ait aucune différence entre ces deux options. – cinnaroll45

Répondre

2

Vous ne mutez pas du tout l'état. La façon dont vous le faites est totalement acceptable. En écrivant ceci

return { 
      ...state, 
      loginRejected: true 
     }; 

Vous créez en fait un nouvel objet avec l'état et renvoyez le nouvel objet sans faire muter l'état. En fait, la façon dont vous faites est une sorte de meilleures pratiques.

+0

Je pensais que c'était peut-être une meilleure pratique de gérer cela dans les actions elles-mêmes plutôt que le réducteur. Mais il semble qu'il n'y ait aucune différence entre ces deux options. – cinnaroll45

+0

Oui, vous pouvez le faire en action, mais la moitié du but du réducteur a disparu et vous allez aussi écrire beaucoup de code dans l'action qui n'est pas correct. –

+1

Il est de la responsabilité du réducteur de modifier l'état actuel et de renvoyer un nouvel état en fonction des actions envoyées sans modifier l'état actuel que vous faites parfaitement ici. –