What could be the downsides of using Redux instead of Flux

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

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.

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.

#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).

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.

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

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

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.