My infuriating frustrations with redux and the redux ecosystem.
Matt McFarland
2913

I can relate to some of the frustration in this article.

My team tried Redux/React/Immutable.js/ES6/Babel/Webpack for an in-house tool back in September. We knew Redux was immature but we did not realize the learning curve was so high. It’s not only Redux who is at “fault”, though. We came from a Backbone/REST API/ES5/AMD background and had to learn all the new concepts at once.

What we really struggled with in the beginning was understanding the concept of the action-reducer-state-view roundabout. It really is a totally different way of thinking as compared to MVC (or MV*). The breaking changes and constant updates of various packages (especially react-router/redux-router) was also a bit frustrating, but we chose an immature project so we can’t complain.

As we started to piece things together, building our app, getting used to the concepts, we got to the next big hurdle. We started to encounter areas in our app that weren’t covered by any Redux examples or docs, e.g. we spent a lot of time integrating our Java REST API. We ended up with a middleware solution that we are not entirely happy with. Our main concern is that we haven’t figured out a way to let the same action post an entry to the API *and* then pass it on to the reducers so the same entry is updated in the state. That is one of today’s problems. Most new Javascript projects have simplistic examples that does not covers any corner cases.

I think the javascript industry is evolving at an awesome pace at the moment. That’s great, but it also means that frameworks/libraries like React and Redux may be relics next year, and that’s not good for anyone.

Show your support

Clapping shows how much you appreciated Jonas’s story.