Live data from Hacker News

Idiomatic Redux: Implementation and Intent

blog.isquaredsoftware.com

1–10 of 88 posts

Re: Idiomatic Redux: Implementation and Intent

#2
Hey, that's my post! :) Actually submitted this to HN previously, but didn't get any traction. Ah, the fickleness of upvotes :)

Spent a lot of time researching for this post. What I really _wanted_ to write was the second half of Part 2 [0], where I gave my opinions on why certain usages are good ideas or bad ideas, but I realized I needed to cover a lot of background before I got there :) Was really cool reading through the original discussions and seeing the vision Dan and Andrew had for Redux from the beginning.

Hopefully this pair of posts helps clarify a lot of the discussion around Redux and its common usage patterns. Also, I'm always happy to answer questions about Redux (and React) usage, and encourage people to come by the Reactiflux chat channels on Discord [1]. Always a great place to learn and ask questions about React, Redux, and related technologies. Finally, if anyone is interested in learning React or Redux, I keep a big list of links to high-quality tutorials and articles on React, Redux, and related topics, at [2]. Specifically intended to be a great starting point for anyone trying to learn the ecosystem, as well as a solid source of good info on more advanced topics.

[0] http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao...

[1] https://www.reactiflux.com

[2] https://github.com/markerikson/react-redux-links

Re: Idiomatic Redux: Implementation and Intent

#3
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.

Re: Idiomatic Redux: Implementation and Intent

#4

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…

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

Re: Idiomatic Redux: Implementation and Intent

#5
post #4

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…

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, ther…

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.

Re: Idiomatic Redux: Implementation and Intent

#6

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…

>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.

Re: Idiomatic Redux: Implementation and Intent

#7
When I first came to React my understanding was that React/Flux were all but a package deal, and that I better use Redux because it seemed so popular. Redux quickly became a pain point in terms of boilerplate and added cognitive load. Now a top level stateful component works for 90% of my use cases.I feel the same way about React Router. Maybe if you're building something quite large or complex these prepackaged tools make sense, but I personally have gone the way of Golang and started to prefer a little copying over adding an extra dependency and I've found that React is wonderful by itself. I encourage anyone who will listen to try ditching Redux in favor of a single top level stateful component.

Re: Idiomatic Redux: Implementation and Intent

#8
post #4

Earlier quoted context omitted.

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, ther…

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.

Re: Idiomatic Redux: Implementation and Intent

#9
Whenever a Redux thread pops up, there's inevitably complaints about "boilerplate". I'd like to pre-empt those complaints a bit by pointing out that, per part 2 of my post, it's entirely up to you how much abstraction you use in your own Redux app. If you want use Redux for a particular use case, someone has probably already written an addon or utility to help solve that problem, and I've got them listed in my Redux addons catalog [0].

If you don't want to edit multiple files, use the "ducks" pattern to put actions and reducers in a single file [1]. If you don't like writing action constants by hand, use one of the dozens of action/reducer generation utilities out there [2] [3]. If you don't want to manage normalized data by hand, there's many addon libraries to help with that [4]. I specifically show off one of them, Redux-ORM [5], in my "Practical Redux" tutorial series [6].

I love all the tools and addons that people are building on top of Redux. One of my favorite quotes is from a Redux issue thread:

> Redux is a generic framework that provides a balance of just enough structure and just enough flexibility. As such, it provides a platform for developers to build customized state management for their use-cases, while being able to reuse things like the graphical debugger or middleware.

A few months ago I opened up a Redux issue thread to discuss further ways that we could help make it easier for people to use Redux, and solve complaints about "boilerplate". The discussion kind of trailed off, but I would love to have more discussion and ideas for building useful new tools on top of and around Redux to help people solve problems and build useful applications. Please join the discussion here: https://github.com/reactjs/redux/issues/2295

[0] https://github.com/markerikson/redux-ecosystem-links

[1] https://github.com/erikras/ducks-modular-redux

[2] https://github.com/markerikson/redux-ecosystem-links/blob/ma...

[3] https://github.com/markerikson/redux-ecosystem-links/blob/ma...

[4] https://github.com/markerikson/redux-ecosystem-links/blob/ma...

[5] https://github.com/tommikaikkonen/redux-orm

[6] http://blog.isquaredsoftware.com/series/practical-redux

Re: Idiomatic Redux: Implementation and Intent

#10

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…

[deleted]
Post reply on HN