The strength of redux is that all your interactions with it are through functions. Redux today is far better than the Redux of yesteryear thanks to things like ReSelect, Thunks, Sagas, Higher Order Components etc. All these things augment Redux, and they can do so because of Redux's open embrace of the humble pure function.

Once you commit to a config based approach, you're basically closing the door to a future you can't imagine yet. I'm so tired of this short-sighted obsession with configuration some developers seem to have.

I think the author has a myopic vision for where Redux should go.

While Redux is great because it enforces a single source of truth, the whole thing with "actions" and "reducers" in Redux is a huge source of boilerplate. In almost every Redux project I have worked on, developers bring in some weird scheme to reduce the boilerplate load of having to come up with a bunch of events when all that anyone wants to do is call some functions.

The fact that Redux forces you to use events to modify the store is a useless complication which has spawned reams and reams of crazy libraries like redux-thunk, redux-saga, standard action formats, etc. The craziest thing yet is Ducks: https://medium.freecodecamp.org/scaling-your-redux-app-with-.... This is a pattern which tries as hard as possible to make using events not feel like using events, by tying each event intimately to its listener.

This library is a step in the right direction, but wrapping Redux seems unnecessary. Here's a similar approach in 100 LOC: https://github.com/didierfranc/react-stateful

> You don’t need to understand what a “comonad” is to use jQuery, and you shouldn’t necessarily need to comprehend functional composition to handle state management.

Is there a point to spreading this piece of sage FUD?

It should not be surprising that pure functions + immutable state results in fewer errors.

The "pattern" Redux asks you to use prevents you from shooting your leg off. If you've written a sizeable application that uses global, mutable state the benefits of Redux shouldn't be surprising.

My only gripe with this eco-system is that it constantly comes up with new names and concepts for things that already exist in the FP world. I agree that the math jargon is off-putting but so is having a dozen words for the same concept. I think the latter is worse.

The library described in the article feels less like an abstraction and more like a shuffling around of syntax. Useful but misleading with a title like, Redesigning Redux.

Update: s/grip/gripe

> Consider time_saved to represent the time you may have spent developing your own solution

Developing your own solution is one thing, and developing your own solution that's as battle tested as a popular library is another.

Baking your own solution helps you understand the core problem that a library you could have used tried to solve. But generally speaking developers that tend to do that have difficulty learning top to bottom and favor bottom up approach which leads them to developing things from scratch. That's just a personal anecdote though.

There are cases were a developer has been using a library for a while and is experienced enough to come up with better solution and cleaner APIs but I'd argue that's not the common case.

Understanding other people's code/libraries is a skill worth mastering.

Is Redux too complex? That's the central argument this article makes but I find it to be patently false. What drew me to redux was its simplicity: Abramov said from the beginning that it's not anything you can't code yourself, it just provides a thin framework around making changes to some base state object. Its main strength (to me) is that it forces developers to think about state changes as mutations rather than recreating a spaghetti state machine oneself.

  1. The constant var `const ACTION_NAME = ...`
  2. The constant's value `... = Symbol('ACTION_NAME')`
  3. The "action creator" function `const doAction = arg => ...` (extra creativity to add a verb here?)
  4. The action creator's return struct: `... => ({ type: ACTION_NAME, payload: arg })`
  5. The reducer switch clause `case ACTION NAME:`
  6. The container action to callback mapping `onClickThing: dispatch(doAction(42))`
  7: The jsx/component calling the callback `onClick={onClickThing}`

  1. The tag on the Msg type: `type Msg = ActionName arg | ...`
  2. The `case` pattern matcher in the update function
  3. The view sending said Msg/action

Nothing on this project solves the real problems and introduces different ones, like how to have a reducer respond to different actions. My quibble with React is that when you get into moderately complicated forms, you start sprinkling stuff all over the place to get the desired output. Take for instance the most popular form library, redux-form. It's very heavy on it's own way of doing things, and there's a lot of stuff you have to know about it to be able to read into what the hell is going on, and it's hard to keep shit in the same place. Reselect is also very heavy handed for what it does. I NEVER needed anything like reselect before redux, and it kinda went alright! In my experience, for any reasonable development with redux you have to introduce: reselect, redux-form, thunk, some sort of immutability (immutable or redux-orm), a sprinkle of compromises and plenty of boilerplate, or roll your own magic util functions (i actually rolled my own very similar stuff to rematch, for quick and dirty stuff). When you summarise all that, it's really not that simple anymore! By the time you get through all of that, you might aswell pick up angular with the added benefit of clearer best practices, nicer dependency injection (oh, but react calls it context so it's cooler!), familiarity and type safety.

It's kinda funny how redux succeeded with such heavy concepts, which is normally not the case. This is still a mistery to me.

Oh and don't get me started on HOC. Want a tooltip over your component? Sure, wrap it in tooltip HOC! Sooo much nicer than directives!

This looks nice, although in Redux's favour is a large ecosystem of libraries that will work with it. This highlights a problem I still have with the JS ecosystem, which is relatively tight coupling between libraries. Of course many of these libraries could be glued together manually without too much work, but with the rapidly changing ecosystem and APIs for interoperability between libraries, and the obscurity of some of the libraries (Redux being a good example), this is often just not practical.

Compare this to Elm and the Elm architecture, and it seems worlds apart. Interoperability between libraries that all works in the same straightforward way, checked by the compiler.

It feels like the JS community made a lot of good decisions for the right reasons, but still ended up in a place that isn't great.

Seems kind of like replacing common functional patterns with esoteric configuration objects?

I've never really understood the point of redux-thunk. But, then, I also don't use asynchronous actions in my datastore.

Asynchronous actions feel, to me, that they belong at the component layer where niceties such as spinners are being rendered, and then the backing store is updated with the results of the triggered action.

What drives people to put all of that into their store?

> Is Redux more performant? No. In fact, it gets slightly slower with each new action that must be handled.

This point is not revisited. What is the performance of Rematch in comparison to Redux? I mean I guess it's more or less the same, since it's essentially Redux with less boilerplate, but it would be nice to have an explicit answer to this.

Can someone explain to me why someone would choose Redux over something like MobX ?

I feel like implements an action for each modification of state (or group of modifications) requires a lot of boilerplate code. In MobX, you treat your data tree as a separate entity, and simply modify it. The UI is automatically updated whenever it needs to.

Mobx isn't bad performance-wise, I think, since it only re-renders the components that are listening to the modified variables when a modification occurs.

The only advantage I see is being able to rewind the state store, which can be quite cool when debugging.

I have done some medium-sized application (only games), and I don't think I've run into any performance or readability problem with MobX. I've never done web apps with a team, though, but I don't think Redux would specially make it easier to work with other programmers.

(To preface, I use React/Redux in all of my web applications. I think Redux is great for managing state.)

One thing I’ve never quite understood about Redux is why we are dispatching pure data instead of a function of state. This would remove the need for reducers, since your action _is_ your reducer. Something like this...

https://gist.github.com/anonymous/a5d741c5dec81be61e0aa70820...

Would this come with any drawbacks? I could see a large application having performance issues because of a large number of function allocations, but for small applications I don’t see a downside, just a simpler API.

This article resonated with me fairly well. As someone who has had an extensive background in Rails and has more recently switched to 100% javascript, this kind of pattern is what the community needs. There's something to be said about getting up and running as quickly as possible. Sure you can make the argument that not everyone's application is the same, but there's a ton of similar patterns that would have been better suited to having less mental gymnastics with a simple config while still leaving the door open with FP for those that want to fine tune.

Isn’t one of the points of redux to decouple actions from reducers? How would you implement multiple reducers responding to a single action if your actions are tied to a reducer with a namespace?

Rematch reminds me of Marty.js. I like some of the ideas about providing a createStore wrapper that is more zero-config and using something like redux-actions to make reducers simpler. I have been using my own wrapper around sagas to allow for dispatching effects.

They lose me with their idea of "models" where I have a global dispatch that can be extended, like dispatch.modelName.actionName. That's just old school object-oriented thinking layered on top of redux's functional programming ideals.

This approach looks really similar to the VueX approach: synchronous reducers are mutations, and async effects are actions. Can't wait to try this out in my next React project.

Nice. I've thought of some of these myself and implemented them as helper functions, but there are some new ideas here I hadn't thought of. Not sure I'm ready to port my project to a new library, but I may try some of these out piecemeal.

I like it. Configuration should be just that. Interested to read other opinions.

should have known it was a ploy for yet another library.

Thunk is not about storing async state in the datastore, it's more akin to multithreading in my opinion.

In backend, you might spin up a thread to do expensive operation like API access, and that thread has it's own database connection, to read and persist data.

With thunk, you dispatch a thunk-ed action to do expensive operation like fetching data from backend, and that action has it's own access to redux in form of `dispatch` / `getState` arguments.

In the end, my component calls `fetchData` function upon mounting. And the logic dealing with making multiple requests due to paging, or re-trying on errors then lives its own life inside a thunk action, independent from the component that spawned it.

Redux is for state management - that could be your data store but many people use it manage their app's UI state as well. Dan Abramov himself has said many times that redux isn't strictly necessary and using local state is fine, but there are some benefits to having a full, serializable application state. You can capture and include it with a bug report/runtime exception for example. Having redux actions dispatched when users interact with your app can also be useful since you get an implicit global event bus. For things like analytics instead of littering calls to your analytics provider in all of your components' click handlers you can write middleware and keep all of that code outside of your presentation/behavior layer.

The problem with putting all async code directly into components is that often, async code is business logic or some other non-view-layer thing that doesn't really belong in a component.

The benefit of redux-thunk (and there are obviously other alternatives that provide the same value) is that it lets you write plain functions that have nothing to do with the store, and nothing to do with components. If you put all your business logic into these plain functions, then they're really easy to test, reason about, move, refactor, etc.

> What drives people to put all of that into their store?

It's worth pointing out that redux-thunk doesn't move async code into your store. The store (i.e. reducers) is still completely synchronous.

> Asynchronous actions feel, to me, that they belong at the component layer where niceties such as spinners are being rendered, and then the backing store is updated with the results of the triggered action.

This is exactly how thunks work, you just fire them from your component as a Redux action. I use thunks primarily for when an action needs to get data from an API and insert it into the store (e.g. on login).

Inverting the question, why would I want my presentational components to do a bunch of extra work beyond presenting? Calling an API is not presentational.

The beauty of Redux and react is that you can do that and nobody's going to tell you you're bad for doing it.

Even Dan Abramov did it in his recent Redux presentation.

It's important that we understand why "best practices" exist but to never see them as commandments. Do what makes sense for your case, but it's your own funeral if you're deviating from best practices without having fully thought it through first.

Part of the idea behind Redux is to keep components as pure as possible and limit side effects to one place, usually actions. You keep all async actions in components?