No, not right. I have work on a daily base with redux unfortunately. Redux is not too hard, but it's poor in design. Also you will have to give up redux soon, the hype is over and better things are at the horizon.

There is definitely some pride in dev's working with redux, once they understand it they feel like they've grown as a developer. Do you really think redux is the holy grail of stores? If you're really smart enough to understand it, think a little deeper about the design, it really sucks.

Try unstated, or is that too simple for you? Do you maybe like a lot of boilerplate and magic that took you a year to grok so you can now show off to others what wizardry you're capable off?

Wow. What an incredibly ignorant and embarrassing point of view.

> Redux is not too hard, but it's poor in design.

You have not once yet stated why it is "poor in design".

> Also you will have to give up redux soon, the hype is over and better things are at the horizon.

I do not care for hype. I am embarrassed for you that you use hype as a measure of a technology's quality.

> There is definitely some pride in dev's working with redux, once they understand it they feel like they've grown as a developer.

You are projecting a point of view onto me that I do not hold. Does this argument tactic usually work?

> Do you really think redux is the holy grail of stores?

No. I do not hold it in higher regarded than what I believe is merited.

> If you're really smart enough to understand it, think a little deeper about the design, it really sucks.

Once again, you say that "it sucks" without giving a valid reason. Do better.

> Try unstated, or is that too simple for you?

Unstated? If you mean "stateless", then I'm not sure what there is to try. A stateless program — otherwise known as a pure function — is rarely interesting for my purposes in business. In all cases, my programs required some persistent state to be modelled.

> Do you maybe like a lot of boilerplate and magic that took you a year to grok so you can now show off to others what wizardry you're capable off?

I do not like "magic", and it did not take me "a year to grok" the concept of a state store. Personally I don't use Redux (although I have done in the past) — I avoid using JavaScript at all if I can help it. Where I need complex UIs, I use Elm. Redux is a JavaScript state store heavily inspired by Elm. It's basically the same, minus type safety (so it's worse).

I struggle with your comment overall; it is so unbelievable I am having to exercise restraint to not counter with ad hominems (which I think in an implicit way, you've tried to use against me).

Wow, relax man! You don't have to defend redux with your life!

I have to work on a daily base with redux because almost every stupid company is using that nowadays. Some codebases are so horrific that I simply quit the job and find something better.

I actually said why it is poor in design: endless switch statements with reducers, do you think that is great design? Every component that wants to use a store needs to 'connect' to it with a higher order component, ever seen chains of hoc's and still know what's going on? Then you need to write time and time again mapStateToProps and mapDispatchToProps. Do you think that's great design? Even if there would be no other state management system yet, it still sucks. Even Dan Abramov says you probably don't need redux, still everyone is using it for the most simple apps.

You might want to use a router, well you're kinda locked into redux so you need redux-router. Example from the redux-router repo:

   import React from 'react';
   import { combineReducers, applyMiddleware, compose, createStore } from 'redux';
   import { reduxReactRouter, routerStateReducer, ReduxRouter } from 'redux-router';
   import { createHistory } from 'history';
   import { Route } from 'react-router';

This, for just wanting to use a fucking router that works along with my store! You think that is great design? React is great design IMHO, not redux. Dan Abramov is a great guy, highly talented, times more intelligent than I am, but his design principles are really poor. Same counts for hooks, a fun experiment for a counter demo, but poor design for larger apps. I hope it will never become a hype too.

Redux is just one of the many flux implementations. Not the best, but a flavour that you may like or dislike. Unstated is a client store that is a wrapper around the new React Context API: unstated: https://github.com/jamiebuilds/unstated

Example of "action-reducer" - combine action and reducer as one IIFE. Use object-path-immutable to update the state.

In any action.ts file you can have as many actions as you wish. Every action has type, dispatch and reduce methods:

  export namespace indexSaveSsl {
    export const type = 'INDEX_SAVE_SSL';
    export const dispatch = (store, response) => {
      store.dispatch({
        type,
        data: response.data
      });
    };
    export const reduce = (state, action) => immutable(state)
      .set('Reports.data.ssl', {})
      .set('Reports.data.ssl.result', action.data)
      .set('Tools.options.ssl.test_running', false)
      .value();
  }

This is typescript namespace, but compiles to IIFE.

This is how actions is combined:

  export const actions = (() => {
    // import main actions via webpack
    const actionsMain = require.context('app/', true, /actions\.ts$/);
    const mainFinal = actionsMain.keys().reduce((prev, key) => Object.assign(prev, actionsMain(key)), {});
    return mainFinal;
  })();

You can call it:

  actions.indexSaveSsl.dispatch(store, resultSsl);

And here how to generate reducers from actions:

  const reducer = (state = {}, action) => {
    // main reducer
    const result = Object.keys(actions)
      .filter((item) => actions[item].type === action.type)
      .map((item) => actions[item].reduce(state, action));
    return result[0] || state;
  };

  createStore(reducer, hydrate, extension);

No switch statements and reducers.

Redux is not "poor in design", rather "poor in implementation". The idea is good, a true single input->update->render cycle, but the reality is tons of boilerplate and stringly-typed code.

I know, you can easily improve it, but from the beginning the docs and most popular helper libaries all point you in the wrong direction.

Can you point to any specific concerns with the docs? We're planning to revamp them in the near future [0], and I'd appreciate any feedback that can help us improve them.

[0] https://github.com/reduxjs/redux/issues/2590

You haven't explained why it's "poor in design".

>better things are at the horizon.

Anything in particular?