Comment prévenir défensivement la mutation de l'état Redux?

Je pense qu'au sein de votre réducteur, si vous créez un nouvel objet à partir de action.payload.abc, vous pouvez être sûr que toute modification de l'objet d'origine n'aura aucun impact sur le magasin de redux.

case SOME_ACTION:
      return { ...state, section1: {...action.payload.abc}};

Il convient de noter que dans votre exemple, la mutation ne posera aucun problème si vous effectuez simplement une copie de niveau appropriée en fonction de l'objet.

Pour abc ressemblant à

code> {a: 1, b: 2, c: 3} vous pouvez simplement faire une copie superficielle tandis que pour un objet imbriqué {a: {name: 1}} vous vous devez le copier en profondeur, mais vous pouvez toujours le faire explicitement sans aucune bibliothèque ou quoi que ce soit.

import produce from 'immer'

export default = (state = initialState, action) =>
  produce(state, draft => {
    switch (action.type) {
      case SOME_ACTION:
        draft.section1 = action.section1;
    })
}

Vous pouvez également empêcher la mutation avec un eslint-plugin-immutable qui forcerait le programmeur à ne pas écrire un tel code.

Comme vous peut voir dans la description du plugin ESLint ci-dessus pour la no-mutation règle :

Cette règle est tout aussi efficace que d'utiliser Object.freeze () pour empêcher les mutations dans vos réducteurs Redux. Cependant, cette règle n'a aucun coût d'exécution. Une bonne alternative à la mutation d'objet est d'utiliser la syntaxe de propagation d'objet fournie dans ES2016.

Un autre moyen relativement simple (sans utiliser de bibliothèque d'immuabilité) pour empêcher activement la mutation est de geler votre état à chaque mise à jour.

import { Map } from 'immutable';

export default function(state = Map(), action) {
  switch(action.type) {
    case SOME_ACTION:
      return state.merge({ section1: action.payload.abc });
      // this creates a new immutable state by adding the abc object into it
      // can also use mergeDeep if abc is nested
  }
  return state;
}

Voici un exemple:

const object = { a: 1, b: 2, c : 3 };
const immutable = Object.freeze(object);
object.a = 5;
console.log(immutable.a); // 1

Object.freeze est une opération superficielle, vous devrez donc geler manuellement le reste de l'objet ou utiliser une bibliothèque comme deep-freeze .

L'approche ci-dessus met la responsabilité de protéger la mutation sur vous.

Un inconvénient de cette approche est qu'il augmente l'effort cognitif nécessaire pour le programmeur en rendant explicite la protection contre les mutations et est donc plus sujet aux bugs (en particulier dans une grande base de code).

Il pourrait également y avoir une surcharge de performance lors de la congélation, en particulier si vous utilisez une bibliothèque conçue pour tester / gérer divers cas extrêmes que votre application particulière n'introduit peut-être jamais.

Une approche plus évolutive consiste à intégrer un modèle d'immuabilité dans votre logique de code, ce qui pousser les modèles de codage naturellement pour des opérations immuables.

Une approche consiste à utiliser Immutable JS où les structures de données elles-mêmes sont construites de telle sorte qu'une opération sur elles crée toujours une nouvelle instance et ne mute jamais.

export default function(state = initialState, action) {
  switch(action.type) {
    case SOME_ACTION:
      return Object.freeze({
        ...state,
        section1: Object.freeze(action.payload.abc)
      });
  }
  return state;
}

Une autre approche consiste à utiliser immer qui cache l'immuabilité dans les coulisses et vous donne des apis mutables en suivant le principe de la copie à l'écriture .

{
  ...state,
  a: {
    ...action.a
  }
}

Cette bibliothèque pourrait bien fonctionner pour vous si vous convertissez une application existante qui a probablement une grande partie du code effectuant la mutation.

L'inconvénient d'une bibliothèque d'immuabilité est qu'elle augmente la barrière à l'entrée votre base de code pour les personnes qui ne connaissent pas la bibliothèque, car maintenant tout le monde doit l'apprendre.

Cela étant dit, un modèle de codage cohérent réduit l'effort cognitif (tout le monde utilise le même modèle) et réduit le facteur de chaos du code (empêche les gens d'inventer leurs propres modèles tout le temps) en restreignant explicitement le la façon dont le code est construit. Cela entraînera naturellement moins de bogues et un développement plus rapide.

Je suis un mainteneur de Redux.

Redux lui-même ne fait rien pour empêcher les mutations de votre état . Cela est en partie dû au fait que Redux ne sait pas ou ne se soucie pas de l'état réel. Il peut s'agir d'un seul nombre, d'objets et de tableaux JS simples, de cartes et de listes Immutable.js, ou autre chose.

Cela dit, il existe plusieurs addons de développement existants qui détectent les mutations accidentelles .

Je vous suggère spécifiquement d'essayer notre nouveau redux-starter-kit package . Il ajoute maintenant le redux-immutable-state-invariant middleware à votre boutique en mode développement par défaut lorsque vous utilisez la fonction configureStore () , et vérifie également l'ajout accidentel de valeurs non sérialisables. De plus, son utilitaire createReducer () vous permet de définir des réducteurs qui simplifient la logique de mise à jour immuable en "mutant" l'état, mais les mises à jour sont en fait appliquées de manière immuable.