People often choose Redux without actually needing it.

“Will our application be scalable without?”.

Then developers complain about the complexity introduced into their code:

“Why do I have to change 3 files to run a feature?”

Indeed, why?

Redux, React, functional programming, immutability, and everything else are blamed for being the source of all the problems and I understand that. It's normal to compare Redux with an approach that doesn't need boilerplate code to update state, and conclude that Redux is just complicated. In a way, it's true, and it's intentional.

Redux offers a contract.

It asks you to commit to:

• Describe application state with simple objects and arrays.
• Describe system changes with simple objects.
• Describe the logic that handles changes with functions.

None of these constraints are necessary to build an app, with or without React. In fact, these are strong constraints and you should think twice before adopting them (even in part) for your app.

Do you have (really) good reasons to do so?

These constraints are appealing because they help build apps that:

• Keep state in local storage and start ready to use
• Pre-populate the state on the server and send it to the client in HTML and start ready to use
• Serialize user actions and a snapshot of state to the automated bug reporting system so developers can replay them to reproduce errors.
• Pass the actions of objects across the network to implement collaborative environments without dramatic changes to the way code is written.
• Maintain undo history or implement optimistic mutations without dramatic changes to how code is written.
• Go back and forth between the development state history and re-evaluate the current state from the action history when the code changes “à la TDD”.
• Offer inspection and control tools so that developers can build custom tools for their apps.
• Offer variations on the UI while reusing business logic

If you are working on a expandable terminal, javascript debugger or a kind of web app, it may be worth considering some of these ideas (which by the way are not to news).
That said, if you're learning React, don't go with Redux by default. Instead, learn to think in React. Come back to Redux if you really feel the need or want to try something new. Use it with caution, as you would with a highly opinionated tool.
If you feel pressured to do “the Redux way”, it may be a sign that you or your team are taking things too seriously. It is neither more nor less than a tool in your toolbox, an experiment here spiral out of control.
Finally, remember that you can implement Redux ideas without using Redux.
For example, here is a React component with local state:

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>
    )
  }
}

It's very good like that. Seriously, it bears repeating:

Local states are fine.

The counterpart that Redux offers is to add indirection to separate “what happened” from “how it changes”.
Is this still a good way to go? No, it's a compromise.
For example, we can extract a reducer from our component:

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>
    )
  }
}

Note that we just used Redux without running npm install. Wow!
Should you do this with your statefull components? Probably not. Actually, not unless you have a plan to take advantage of this additional indirection. Having a plan, in our jargon, is key.
The Redux library is a set of helpers for mounting reducers into a global storage object. You can use it with or without moderation.
But if you use it, make sure you get something in return...
Original article de Dan Abramov
https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367#.k0dntcu9w
translated from English by JS Staff
[separator type=”” size=”” icon=”star”] [actionbox color=”default” title=”” description=”JS-REPUBLIC is a service company specializing in JavaScript development. We are an approved training center. Find all our technical training on our partner site dedicated to Training” btn_label=”Our training” btn_link=”http://training.ux-republic.com” btn_color=”primary” btn_size=”big” btn_icon=”star” btn_external =”1″]