What could be the downsides of using Redux instead of Flux [closed]

Question

I just recently discovered Redux. It all looks good. Are there any downsides, gotcha or compromises of using Redux over Flux? Thanks

Navada

Answer 1

Redux author here!

I'd like to say you're going to make the following compromises using it:

• You'll need to learn to avoid mutations. Flux is unopinionated about mutating data, but Redux doesn't like mutations and many packages complementary to Redux assume you never mutate the state. You can enforce this with dev-only packages like redux-immutable-state-invariant, use Immutable.js, or trust yourself and your team to write non-mutative code, but it's something you need to be aware of, and this needs to be a conscious decision accepted by your team.

• You're going to have to carefully pick your packages. While Flux explicitly doesn't try to solve “nearby” problems such as undo/redo, persistence, or forms, Redux has extension points such as middleware and store enhancers, and it has spawned a young but rich ecosystem. This means most packages are new ideas and haven't received the critical mass of usage yet. You might depend on something that will be clearly a bad idea a few months later on, but it's hard to tell just yet.

• You won't have a nice Flow integration yet. Flux currently lets you do very impressive static type checks which Redux doesn't support yet. We'll get there, but it will take some time.

I think the first is the biggest hurdle for the beginners, the second can be a problem for over-enthusiastic early adopters, and the third is my personal pet peeve. Other than that, I don't think using Redux brings any particular downsides that Flux avoids, and some people say it even has some upsides compared to Flux.

---

See also my answer on upsides of using Redux.

Lovelovebird

Awesome answer. Is there a simple explanation of why mutations are avoided in redux and the complementary packages? – Electromagnetism

In short, mutations make it hard to check which parts of state changed to efficiently redraw only changed parts of UI. They also make debugging harder, and libraries like github.com/omnidan/redux-undo impossible. Finally time travel in github.com/gaearon/redux-devtools would not work if state was mutated. – Lovelovebird

@DanAbramov how does immutability help to have efficient redraws in Redux? E.g. in react-redux shallowEqual check is used to determined if the state changed. But it can be replaced with deepEqual or JSON.stringify and compare. Eventually it's somewhat lower performance - but it's pure computations without dealing with DOM - so fast enough. And in any case rendering itself is the same – Classless

@Classless deepEqual or JSON.stringify are quite slow. They're not "fast enough" for real apps, especially if you compare data for every view. – Lovelovebird

Ok, I got it. Sounds that immutability makes dirty checks more efficient, rather than making redraw more efficient. – Classless

@DanAbramov In such an opinionated industry it's very refreshing to see someone (especially the author) providing both the pros and cons of software packages/libraries. This is how discussions about software should take place and how informed decisions are made, rather than the "newest library on the block" approach. Please keep it up! – Finalism

Answer 2

Both Redux and Flux require a considerable amount of boilerplate code to cover many common patterns, especially those that involve asynchronous data fetching. The Redux documentation already has a handful of examples for boilerplate reduction: http://redux.js.org/docs/recipes/ReducingBoilerplate.html. You could get everything you might need from a Flux library like Alt or Fluxxor, but Redux prefers freedom over features. This could be a downside for some developers because Redux makes certain assumptions about your state that could be inadvertently disregarded.

The only way for you to really answer your question is to try Redux if you can, perhaps in a personal project. Redux came about because of a need for better developer experience, and it is biased towards functional programming. If you aren't familiar with functional concepts like reducers and function composition then you might be slowed down, but only slightly. The upside for embracing these ideas in data flow is easier testing and predictability.

Disclaimer: I migrated from Flummox (a popular Flux implementation) to Redux and the upsides far outweigh any downsides. I prefer much less magic in my code. Less magic comes at a cost of a little more boilerplate, but it's a very small price to pay.

Boatel

Answer 3

Flux and Redux . . .

Redux is not a pure Flux implementation but definitely inspired by Flux. Biggest difference is that it uses a single store that wraps a state object containing all the state for your application. Instead of creating stores like you'll do in Flux, you'll write reducer functions that will change a single object state. This object represent all the state in your app. In Redux you will get the current action and state, and return a new state. That mean that actions are sequential and state is immutable. That bring me to the most obvious con in Redux (in my opinion).

---

Redux is supporting an immutable concept.

Why Immutability?

There are few reasons for that:
1. Coherence - store's state is always being changed by a reducer so it's easy tracking who change what.
2. Performance - because it's immutable, Redux only need to check if previous state !== current state and if so to render. No need to loop the state every single time to determined rendering.
3. Debugging - new awesome concepts like Time Travel Debugging and Hot Reloading.

UPDATE: if that wasn't persuading enough, watch Lee Byron excellent talk about Immutable User Interfaces.

Redux require a developer(s) discipline through the codebase/libraries to maintain this idea. You'll need to make sure you pick libraries and write code in a non-mutable manner.

If you'd like to learn more about the different implementation of Flux concepts (and what works best for your needs), check out this useful comparison.

After said that, I must admit that Redux is where JS future development is going to (as for writing these lines).

Taurine

Answer 4

One of the largest benefits in using Redux over the other Flux alternatives is its ability to reorient your thinking towards a more functional approach. Once you understand how the wires all connect you realize its stunning elegance and simplicity in design, and can never go back.

Fao

Answer 5

I prefer using Redux as it uses one store which makes state management much easier compare to Flux, also Redux DevTools it's really helpful tools which let you see what you doing with your state with some useful data and it's really inline with React developing tools.

Also Redux has got more flexibility using with other popular frameworks like Angular. Anyway, let's see how Redux introduces himself as a framework.

Redux has Three Principles which can introduced Redux very well and they are the main difference between Redux and Flux also.

Single source of truth

The state of your whole application is stored in an object tree within a single store.

This makes it easy to create universal apps, as the state from your server can be serialized and hydrated into the client with no extra coding effort. A single state tree also makes it easier to debug or inspect an application; it also enables you to persist your app's state in development, for a faster development cycle. Some functionality which has been traditionally difficult to implement - Undo/Redo, for example - can suddenly become trivial to implement, if all of your state is stored in a single tree.

console.log(store.getState())

/* Prints
{
  visibilityFilter: 'SHOW_ALL',
  todos: [
    {
      text: 'Consider using Redux',
      completed: true,
    },
    {
      text: 'Keep all state in a single tree',
      completed: false
    }
  ]
}
*/

State is read-only

The only way to change the state is to emit an action, an object describing what happened.

This ensures that neither the views nor the network callbacks will ever write directly to the state. Instead, they express an intent to transform the state. Because all changes are centralized and happen one by one in a strict order, there are no subtle race conditions to watch out for. As actions are just plain objects, they can be logged, serialized, stored, and later replayed for debugging or testing purposes.

store.dispatch({
  type: 'COMPLETE_TODO',
  index: 1
})

store.dispatch({
  type: 'SET_VISIBILITY_FILTER',
  filter: 'SHOW_COMPLETED'
})

Changes are made with pure functions

To specify how the state tree is transformed by actions, you write pure reducers.

Reducers are just pure functions that take the previous state and an action, and return the next state. Remember to return new state objects, instead of mutating the previous state. You can start with a single reducer, and as your app grows, split it off into smaller reducers that manage specific parts of the state tree. Because reducers are just functions, you can control the order in which they are called, pass additional data, or even make reusable reducers for common tasks such as pagination.

function visibilityFilter(state = 'SHOW_ALL', action) {
  switch (action.type) {
    case 'SET_VISIBILITY_FILTER':
      return action.filter
    default:
      return state
  }
}

function todos(state = [], action) {
  switch (action.type) {
    case 'ADD_TODO':
      return [
        ...state,
        {
          text: action.text,
          completed: false
        }
      ]
    case 'COMPLETE_TODO':
      return state.map((todo, index) => {
        if (index === action.index) {
          return Object.assign({}, todo, {
            completed: true
          })
        }
        return todo
      })
    default:
      return state
  }
}

import { combineReducers, createStore } from 'redux'
let reducer = combineReducers({ visibilityFilter, todos })
let store = createStore(reducer)

for more info visit here

Hardenberg

Answer 6

Redux require discipline regarding to immutability. Something I can recommend is ng-freeze to let you know about any accidental state mutation.

Fleabag

Answer 7

As far as I know, redux is inspired by flux. flux is an architecture like MVC (model view controller). facebook introduce the flux due to scalability problem when using MVC. so flux is not an implementation, it just a concept. Actually redux is the implementation of flux.

Pettit