Hacker News Reader

Comment by forgottenacc57 | Hacker News Reader

This article serves only to reinforce that the beautiful simplicity of react is spoilt by the confusion of Redux.

I feel that every Redux blog post should start by pointing out that despite react/Redux almost being discusssed synonymously, as the author of Redux points out, "you might not need Redux".

I would go further and say "avoid Redux until you know you need it", and point people to more simple ways of reaching the same goals.

Redux is a power tool for experts that is disheartening beginners and sending them down the wrong path.

I was speaking to someone recently who had tried Reactjs. I wanted to enthuse with him about how awesome it is. He said it was too hard and he went with vuejs instead. When I questioned him further it became apparent that he had started to learn react/Redux and gave up in confusion.

View on HN

>Redux is a power tool for experts that is disheartening beginners and sending them down the wrong path.

I've seen this expressed many, many times, and it is something that I've honestly never quite understood. I started with React less than a year ago, and it wasn't until I added Redux to my stack that I began to feel perfectly comfortable with,

To me, the fact that actions dispatched in whatever component would cause the global state to be recomputed which then got handed to react to render it just a no-brainer. This truly makes data in React flow just one direction. The tooling around it -- Redux DevTools -- also made seeing my app in action and debugging it so incredibly clear.

Without it, for me initially it was a struggle about where exactly to store certain state, and passing props and callbacks up and down all over the place. It wasn't clean or easy to reason about at all.

As someone who had very limited experience in the framework, Redux felt like a tool which made the pit of success for me pretty darn large. I do know that even Dan himself has suggested that people not learn them in conjunction, but to me, the coupling of them is so perfect that React only became a joy to use WHEN I introduced it.

Redux is conceptually simple and really helps in attaining a highly decoupled and resilient architecture, but it shares the same configuration-over-convention mindset as the rest of the js/node world. Once you get all the little modular pieces assembled just right, it's great to work with, but it can be quite a struggle to reach that point. There are also a bunch more libraries you need beyond just redux to make things really hum the way they're supposed to.

> I've seen this expressed many, many times, and it is something that I've honestly never quite understood.

Well, if you're coming in from a non-FP background, learning Redux is intimidating. I'm a aspiring web developer (I'm coming from tech support role and my programming skill is mostly bash and bit of Python) and started looking into Redux, and yay struggled with getting started.

  const store = createStore(reducer)

Took me hundreds of console.log ('entering func blah blah') before I realize out that those reducers become properties of the object store. So yes, Redux is power tool for expert and not as nearly accessible to your average neighborhood web developer.

I'd be very happy to discuss any pain points or particular problems you've run into trying to learn Redux, and any suggestions you might have for improving the docs to make it easier for others in the future. Please feel free to ping me on Twitter, or in the Reactiflux chat channels.

My thoughts exactly!

The amount of things you need to know in order to use react and redux is ridiculously low.

You're basically just composing functions of two types "(state, action) => state" , and "state" => html.

The boilerplate consists of a few functions (really mostly createStore and connect) that are incredibly well documented.

There's almost nothing to understand and redux itself is almost not a lib (only 318 LOC). The whole thing is a pattern and redux is just a small, very well written key component of the pattern.

When people debate redux they debate about programming, not about a tool. That's why it's interesting and why it will never end.

Yes, and no.

Per your quote, Dan Abramov (creator of Redux) advises that people should focus on learning React first, and _then_ try to learn Redux. I'm one of Redux's current maintainers, and I completely agree with that advice. (My "standard advice for learning React" includes exactly that instruction.)

However, while it's absolutely possible to build a React app without an additional state management library, there _are_ excellent reasons to move most of your state outside the component tree: simpler props passing, optimized app performance with less re-rendering, and the ability to maintain more of your application's current state in the middle of hot module reloading. And, in the case of Redux specifically: benefits like time travel debugging, centralized middleware for dozens of use cases, more easily testable code, and the ability to straightforwardly trace data flow through the system.

A lot of the issues I see with people trying to learn Redux are more about people who either have little JS or React experience to begin with, or are completely used to OOP, and are having issues trying to get used to functional programming principles in general.

Is Redux for everybody? No. Should it be the first thing that a learner jumps into? Probably not.

Does Redux help solve real problems for front-end developers? Definitely.

(Note: In addition to "You Might Not Need Redux" [0], it's fascinating to read Dan's earlier pre-Redux article "The Case for Flux" [1], where he not only discusses the benefits of using the Flux Architecture to solve use cases like caching data on the client, but also argues against doing things purely out of dogma: "A dogma is born when the solutions are presented without enough original context, and newcomers feel pressured to delegate crucial decisions to an authority." So in that sense, yes, I'd absolutely agree that newbies are being pushed to use Redux out of dogma, but disagree that learning to use Redux is a bad thing.)

[0] https://medium.com/@dan_abramov/you-might-not-need-redux-be4...

[1] https://medium.com/swlh/the-case-for-flux-379b7d1982c6

I don't question the value of Redux, only that, as is acknowledged by DA, it's not required for reactjs.

The problem is because the community reveres Redux so highly that react and Redux are coming to be equated as a pair. Not much you Redux developers can do about that, it's a testament to the value of your work.

Yeah, based on some vague stats, I'd guess that around 60% of React projects are also using Redux. (That's based on the "State of JS 2016" survey, a Twitter poll asking React devs what state management system they're using, and some NPM download stats I think I saw.) So yes, for better or for worse, there is both an assumption that they go together automatically, and a reason for that assumption.

Also worth noting that Redux can absolutely be used with any UI layer, _is_ being used with frameworks like Angular and Ember, and has also inspired variations like vuex and ngrx/store.

Redux itself is boilerplate heavy but conceptually pretty easy to understand. But once you start building real world apps and have to deal with async actions things get a lot more complicated and a lot of the benefits of the redux model evaporate. I plan to use mobx on my next react app.

Redux-saga helps a lot for this. It has a bit of a learning curve, but it's an extremely elegant way of dealing with tricky asynchronous workflows once you get a feel for it. I think it's actually my favorite lib in the redux ecosystem.

Redux saga provides a nice syntax I agree but leans on some fairly advanced JS concepts. It's a lot to ask a beginner to digest just to display some data from a REST endpoint.

I went from Redux to MobX in one of my recent projects and it was a breath of fresh air. It's so much easier to work with, and more performant in my situation, too.

Mobx doesn't do anything to alleviate the complexity that comes eith asynchronicity. It does help with boilerplate, though.

I think most people are more comfortable with object composition rather than function composition, so Mobx feels more natural.

Just when i thought i finally need Redux when i hit a roadblock in React Native, i found simply adopting a global event emitter (like my existing React website with addEventListener) still works like a charm. When i tried using Redux i felt something is not right, i felt it is very overkill for most of the use cases. It has the same feeling that i didn't adopt Angular and stuck with Rails until React came along.

Same here.

I added a event emitter to AsyncStorage and that's basically it.

If your React application is spoilt by Redux you're doing something wrong. The whole point of Redux is that the majority of your code is simple idiomatic React that knows nothing about the global state.

Reply on news.ycombinator.com