Les gens choisissent souvent Redux sans en avoir réellement besoin.

“Notre application sera-t-elle scalable sans ?”.

Ensuite les développeurs se plaignent de la complexité introduite dans leur code:

“Pourquoi dois-je changer 3 fichier pour faire tourner une fonctionnalité ?”

En effet, pourquoi ?

On reproche à Redux, React, le functional programming, l’immutabilité, et tutti quanti, d’être la source de tous les problèmes et je le comprends ça. C’est normal de comparer Redux avec une approche qui n’aurait pas besoin de code “boilerplate” pour mettre à jour le state, et conclure que Redux est juste compliqué. D’une certaine façon, c’est vrai, et c’est intentionnel.

Redux propose un contrat.

Il vous demande de vous engager à :

• Décrire l’état de l’application avec des objets simples et des arrays.
• Décrire les changement du système avec des objets simples.
• Décrire la logique qui gère les changements avec des des fonctions.

Aucune de ces contraintes n’est nécessaire à la construction d’une app, avec ou sans React. En fait, il s’agit de de contraintes fortes et vous devriez y réfléchir à deux fois avant de les adopter (même en partie) pour votre app.

Avez vous (vraiment) de bonnes raisons de le faire ?

Ces contraintes sont séduisantes car elles aident à construire des app qui :

• Conservent le state dans un stockage local et démarrent prêtes à l’emploi
• Pré-remplissent le state sur le serveur et l’envoient au client en HTML et démarrent prêtes à l’emploi
• Sérializent les actions utilisateur et une photographie du state au système automatisé de bug reports de sorte que les développeurs puissent les rejouer afin de reproduire les erreurs.
• Passent les actions des objets au travers du réseau afin de mettre en oeuvre les environnements collaboratifs sans changements spectaculaires sur la façon dont le code est écrit.
• Maintiennent l’historique des undo ou implémentent les mutations optimistes sans changements spectaculaires sur la façon dont le code est écrit.
• Font l’aller et retour entre l’historique des states en développement et ré-évaluent le current state depuis l’historique des actions quand le code change “à la TDD”.
• Proposent des outils d’inspection et de contrôle afin que les développeurs puissent construire les outils customs pour leurs apps.
• Proposent des variantes sur l’UI tout en réutilisant la logique business

Si vous travaillez sur un terminal extensible, un debugger javascript ou un genre de webapp, ça peut valoir la peine de considérer certaines de ces idées (qui d’ailleurs ne sont pas nouvelles).
Ceci dit, si vous apprenez React, ne partez pas avec Redux par défaut. Apprenez plutôt à réfléchir en React. Revenez à Redux si vous en éprouvez réellement le besoin ou si vous voulez essayer quelque chose de nouveau. Utilisez le avec prudence, comme vous le feriez avec un outil très dogmatiques.
Si vous vous sentez la pression pour faire “à la manière de Redux”, c’est peut-être un signe que vous ou votre équipe prenez les choses trop au sérieux. Ce n’est ni plus ni moins qu’un outil dans votre boite à outil, une expérience qui a échappé à tout contrôle.
Pour terminer, n’oubliez pas que vous pouvez mettre en oeuvre les idées de Redux sans utiliser Redux.
Par exemple, voici un composant React avec un state local :

import React, { Component } from 'react';
class Counter extends Component {
  state = { value: 0 };
  increment = () => {
    this.setState(prevState => ({
      value: prevState.value + 1
    }));
  };
  decrement = () => {
    this.setState(prevState => ({
      value: prevState.value - 1
    }));
  };
  render() {
    return (
      <div>
        {this.state.value}
        <button onClick={this.increment}>+</button>
        <button onClick={this.decrement}>-</button>
      </div>
    )
  }
}

C’est très bien comme ça. Sérieusement, ça vaut le coup de le répéter :

Les states locaux, c’est bien.

La contrepartie que Redux propose est d’ajouter l’indirection pour séparer “ce qui est arrivé” de “comment ça change”.
Est-ce toujours une bonne façon de faire ? Non, c’est un compromis.
Par exemple, on peut extraire un reducer de notre composant:

import React, { Component } from 'react';
const counter = (state = { value: 0 }, action) => {
  switch (action.type) {
    case 'INCREMENT':
      return { value: state.value + 1 };
    case 'DECREMENT':
      return { value: state.value - 1 };
    default:
      return state;
  }
}
class Counter extends Component {
  state = counter(undefined, {});
  dispatch(action) {
    this.setState(prevState => counter(prevState, action));
  }
  increment = () => {
    this.dispatch({ type: 'INCREMENT' });
  };
  decrement = () => {
    this.dispatch({ type: 'DECREMENT' });
  };
  render() {
    return (
      <div>
        {this.state.value}
        <button onClick={this.increment}>+</button>
        <button onClick={this.decrement}>-</button>
      </div>
    )
  }
}

Notez bien que nous avons juste utilisé Redux sans faire tourner npm install. Waouw !
Devriez vous faire ça avec vos composants statefull ? Sans doute que non. En fait, non sauf si vous avez un plan pour tirer parti de cette indirection additionnelle. Avoir un plan, dans notre jargon, c’est la clé.
La librairie Redux est un ensemble d’assistants pour monter des reducers dans un objet de stockage global. Vous pouvez l’utiliser avec ou sans modération.
Mais si vous l’utilisez, faites en sorte d’obtenir quelque chose en retour…
Article original de Dan Abramov
https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367#.k0dntcu9w
traduit de l’anglais par JS Staff
[separator type=”” size=”” icon=”star”] [actionbox color=”default” title=”” description=”JS-REPUBLIC est une société de services spécialisée dans le développement JavaScript. Nous sommes centre de formation agréé. Retrouvez toutes nos formations techniques sur notre site partenaire dédié au Training” btn_label=”Nos formations” btn_link=”http://training.ux-republic.com” btn_color=”primary” btn_size=”big” btn_icon=”star” btn_external=”1″]