[acemarke]

I agree that "only use functional components" is a heavily over-opinionated approach (I actually tweeted a counter-statement to that recently: https://twitter.com/acemarke/status/855192917727735808 ).

There _are_ definitely a number of benefits to using Redux in a React app. I actually co-authored an article that discusses some of them: https://www.fullstackreact.com/articles/redux-with-mark-erik... . TL;DR: time-travel debugging and better hot reloading for development, easier management of data that needs to be used in multiple places throughout the component tree, and all the niceties of having centralized state (logging, state persistence, issue reporting, etc).

[ashark]

I'm beginning to think there'd be a way to make Redux a helluva lot clearer by sticking everything in a class with a well-defined interface (but: ewwwww, classes, impure, burn the heretic!). Keep all the definitions for an actioncreator, event (action), and its reducer in one place. Hand the whole class to Redux and forget about it. Can compose actions/reducers inside those classes if you want/need to, so no loss there.

The pile o' reducers thing just isn't a very useful way to organize code IMO, and having everything split over several files makes following what's happening a PITA (especially without something like Typescript to let your tools give you the information you need, rather than having to keep it in your head or go look it up manually).

Redux feels... not over-engineered, exactly, but maybe mis-engineered.

... or we could just cut out the middleman and go all Actor model on this problem. Just sayin'. (yes, I know there are actor-model libs for React out there, but frankly the churn-related breakage and confusion in the most popular tools is so bad I'm afraid to step outside the mainstream, where it's probably even worse—plus we don't get to choose our own libs/patterns all of the time)

[scriptkiddy]

>I'm beginning to think there'd be a way to make Redux a helluva lot clearer by sticking everything in a class with a well-defined interface (but: ewwwww, classes, impure, burn the heretic!).

I thought the same thing. That's why I started using VueJS with Vuex. Vuex accomplishes the same things as redux in a much more manageable and centralized manner. Plus, you don't have to worry about connecting your components to the store through `react-redux` or whatever. With Vue and Vuex, you just pass the store object to the root view component and it's available in every single child component via `this.$store`. You can then `dispatch` actions which perform `commits` which call `mutations` which update the state. Then, in your component you create a computed property that uses a `getter` to return the piece of application state you want. It's a really simple top down data flow and everything is namespaced. It's so absurdly simple and easy that I don't understand why redux doesn't take a page from vuex's book.

I really should write a Vue + Vuex tutorial for beginners as I'm super happy with the way it works.

[shados]

You don't even need a class, but either way, this is essentially how Elm works.

There are very different semantics at work there though. Elm is Fractal, Redux is not. Each have tradeoffs. Some stuff gets simpler, some stuff gets harder (the 1:1:1 scenario where you have a component, an action, and a reducer to achieve 1 thing gets easier. The N to N to N scenario where a reducer can handle things from all over the system, gets harder).

It's not misengineered, its just optimized to make a different set of problems easier at the cost of making others harder.

[acemarke]

There's already a whole bunch of "define Redux action creators and reducers as classes" libraries out there. I've added the ones I've seen to my Redux addons catalog, in the "Variations" category: https://github.com/markerikson/redux-ecosystem-links/blob/ma... (which is where I list stuff that builds on Redux, but takes it in a "non-idiomatic" direction).

There's definitely several different schools of thought about how to organize and structure Redux-based code. Dan is a big fan of the "small independent slice reducers responding separately to the same action" approach. Others prefer to see all possible state changes for a given action in one place. And yes, while the intended use of Redux is based on functional programming, there's also those who prefer putting OOP layers on top.

I'm actually working on a blog post that will try to clarify and discuss what actual technical limitations Redux requires of you, vs how you are _encouraged_ to use Redux, vs how it's _possible_ to use Redux. Been busy with other stuff, but hoping to make progress on that post this week. If you're interested, keep an eye on my blog at http://blog.isquaredsoftware.com .

You may also be interested in an issue I recently opened to discuss possible future improvements and "ease-of-use" layers that could be built on top of the Redux core: https://github.com/reactjs/redux/issues/2295 .

Finally, I'm always happy to chat about Redux (and React) over in the Reactiflux chat channels on Discord. The invite link is at https://www.reactiflux.com . Feel free to drop by and ping me.