Hacker News Reader

Comment by Karupan | Hacker News Reader

Redux was such a mental overhead for me when I started out with it. The amount of boilerplate code that I had to write for the project I worked on was very frustrating. What helped me truly understand the concept was Elm.

These days I ask junior devs to learn Elm for a few days. We still use Redux, I will not choose it for new projects.

View on HN

I see the Redux devs defending their tool in every comment thread around Redux and I have to say to them: it's not your fault and there's not a lot you can do to fix it by yourselves. The problem is every tutorial and training and boot camp and video I've ever seen around Redux treats Redux like heavyweight boilerplate and teaches you that you need five files with Redux where you only needed one with plain React and every function you add needs to touch all five of those files, including a file that only exists to write the name of the function you've added.

What I hear from the Redux devs does not in any way line up with what I heard from Brad Traversy or Stephen Grider, who have taught tens (hundreds?) of thousands of people on Udemy that the simplest React projects must be used with Redux and Redux turns beautiful React code into dotcom-era Enterprise Java.

Yeah, unfortunately once something gets a large community, it takes on a life of its own.

Part of the issue is that the Redux docs _do_ show many of these patterns (`const ADD_TODO = "ADD_TODO"`, separate files and folders for constants / actions / reducers, etc). Dan has said several times that he didn't expect folks to literally mimic everything that was shown in the docs, but tbh that's what people do. He's also said he wishes he'd emphasized teaching it in some different ways.

We're doing everything we can to try to teach better practices and patterns now, but that can't magically change the gazillions of existing tutorials and codebases that are out there.

> didn't expect folks to literally mimic everything that was shown in the docs

Isn't that the point of documentation? To give you a reasonable, suggested way of incorporating a library into an existing project? This is almost saying, "the docs were wrong and everyone learned the wrong thing". I don't think you can blame package users for that. People reference documentation to know what to do, and also what to avoid, when using a new library.

Yeah, I know. I'm not blaming Dan here, specifically, just repeating what he's said several times himself.

That's why we're doing the docs rewrite. The target audiences have changed since 2015 (new devs learning Redux in a bootcamp vs folks coming from other Flux libraries), we've got a better understanding of how Redux should be used, and we want to set folks on a better path from the beginning.

People need standardization. The docs are usually the source of truth or go-to for any disputes. Whatever's written there is the best practice since literally everyone who uses it would have read it.

I'm the mentioned Stephen Grider - to clarify, I don't advocate using Redux on every project by any means, and I apologize if I said anything in my course to that effect.

Instead, I advocate using Redux on larger projects - especially as a beginner - because it naturally provides some structure. There is a large community of engineers that advocates using as few libraries as possible. I generally agree with that sentiment, but not for beginner engineers. A beginner engineer doesn't have the skills necessary to architect a large project from scratch (hence the 'beginner' designation), and can benefit from being given a bit more rigid structure.

And that's a valid approach, I learned React (and unfortunately Redux) from your courses and they're very high quality. I really do appreciate the handful of your courses I've bought and owe you a lot more than the $10 I paid for the Udemy video.

However, it is exceedingly difficult to find any React tutorial that doesn't have Redux, making it seem to beginners that Redux is required for React. And Redux is entirely overwhelming, especially for a newbie like when I was learning React. It took me three or four courses until I was comfortable and knowledgable enough to strip Redux from my projects, and after that my speed and productivity skyrocketed.

When I was first learning React from your video, I'll admit I turned it off several times, frustrated with the mindset that I was never going to learn React and React was stupid because what do you mean I need to hydrate a store and map state to props and maintain a file listing all of the functions I have? Turns out it's just Redux that I hate. React is fine. And without experiencing the pain that Redux solves, Redux (to me, as a beginner) just seems like completely unnecessary boilerplate that keeps me out of the React ecosystem.

Anyway that's just one person's feedback. I'm sure Redux solves some very real pains, but to me as a beginner, Redux is more of a pain than the problem it's designed to solve (because I've never experienced the problem it's designed to solve) and it is very difficult to find a high-quality course or demo project that doesn't include it.

FWIW, our recommendation has always been to focus on learning React first, and _then_ learn Redux once you're comfortable with React. That minimizes the number of new concepts you're learning at once, clarifies the differences between what React and Redux are and how to use them, and helps show why Redux might be useful alongside React.

Which leads nicely back to my statement of

>What I hear from the Redux devs does not in any way line up with what I heard from Brad Traversy or Stephen Grider

This perception will continue (and only get worse) the more junior devs are educated in trainings/bootcamps that require Redux in your first project. This is the reason so many people have such negative reactions to Redux, they're not yet comfortable with React (which is a new way of thinking by itself) before Redux is added into the mix and it gets very overwhelming very quickly.

OTOH, any sufficiently complicated React app contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Redux.

OTOOH, react et al are just attempts to make the asynch web synchronous.

Request/response cycle returns a resource, including embedded resources, and we get over it and move on in life.

Now, how on earth a folder-index-sharing protocol for hyperlinking became the planets default UI surface for everything ever, that's another ball of wax to fry another day, killed with the same stone as the mythical 2 birds, etc.

Please try out our new official Redux Toolkit package, which will help simplify your Redux logic considerably:

https://redux-toolkit.js.org

or Rematch.

http://rematch.github.io/

Right see, this is what all redux proponents advocate. Every redux project I see is chock-ful of "extras" to make redux workable, and this changes from season to season. If this isn't an architectural smell, I don't know what is.

Not sure why different libraries would be an architectural smell. Not only Redux projects vary greatly in what they bolt onto their state management. I've used Redux successfully on its own. The dataflow pattern it mandates is important, not the concrete implementation.

You can use the built-in IoC controller or Autofac or ServiceStack or whatever you want along with ASP.NET Core projects. I don't think it is architectural smell at all.

Also I find classifying people as Redux-proponents funny. It's not a camp, or at least not supposed to be one.

Redux itself is a very simple concept. There is so much boilerplate because the actual library makes very few opinionated decisions. The issue is that people are looking for something comprehensive from what is supposed to be a minimal base library which you can use to build a huge variety of other things.

That link is a 404, looks like the site is here: https://rematch.github.io/rematch/

Thanks, will check it out. Unfortunately, it only adds to the dependency hell in the front-end stack. We already use quite a few add-ons to make Redux+Sagas tolerable.

My personal take on the whole JS + Redux stack is that Redux tries to bring order to a language which fundamentally doesn't support certain traits - immutability, custom types, etc. While commendable, it will always just be a band-aid. I wonder if it's time to move to more purpose built languages which do not have these shortcomings (Elm, PureScript, etc)

That said, I'm sure Redux and friends will continue to be used in the years to come.

It's such a shame that redux missed the equivalent of returning a Cmd in reducers. It would have made everything much simpler and reasonable, especially the boilerplate.

Reply on news.ycombinator.com