Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Idiomatic Redux: Implementation and Intent

blog.isquaredsoftware.com

Post reply on HN
Print view View original

11–20 of 88 posts

Re: Idiomatic Redux: Implementation and Intent

#11

Post by learc83 »

toprerules wrote: post #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 tool…

I wouldn't recommend this at all. Sure if you have a tiny site with very limited functionality or you're learning react, you don't need redux.

But if you're using components they way they're intended, (not cramming everything into a few overloaded components), you're quickly going to be passing down props down through layers and layers. It will quickly become a maintenance nightmare.

Just imagine that you have a button component that is 5 or layers down from you're stateful component. It's getting props to control it's state passed down through all 5 levels, and it's getting functions to change the stateful component's state passed down through all 5 levels. Now what happens when you want to move the button from your side bar to your footer?

Redux solves a very real problem, there are other solutions to this same problem, but eventually any non-trivial app is going to need something for state management beyond a single top level stateful component.

Re: Idiomatic Redux: Implementation and Intent

#12

Post by zepolen »

learc83 wrote: post #11
toprerules wrote: post #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 tool…

I wouldn't recommend this at all. Sure if you have a tiny site with very limited functionality or you're learning react, you don't need redux. But if you're using components they way they're intended, (not cramming everything into a few overloaded components), you're quickly going to be passing down props down through layers and layers. It will quickly become a maintenance nightmare. Just imagine that you have a butt…

How does using Redux solve the tons of props through layers problem?

Re: Idiomatic Redux: Implementation and Intent

#13

Post by acemarke »

zepolen wrote: post #12
learc83 wrote: post #11

Earlier quoted context omitted.

I wouldn't recommend this at all. Sure if you have a tiny site with very limited functionality or you're learning react, you don't need redux. But if you're using components they way they're intended, (not cramming everything into a few overloaded components), you're quickly going to be passing down props down through layers and layers. It will quickly become a maintenance nightmare. Just imagine that you have a butt…

How does using Redux solve the tons of props through layers problem?

Because you can use the React-Redux `connect()` function to wrap any component in your tree with a "container component" that automatically subscribes to the Redux store, extracts the data you want for that component, and passes it straight in. That way, the upper components in your application don't need to know that a leaf component happens to need a specific value and pass it down through N levels of components - that one component just grabs the data it needs from the store. A good example of this would be a list or a treeview, where every list item or treeview node is itself connected to the store.

I talked about some of the benefits of using Redux in a React application in a post I co-wrote: https://www.fullstackreact.com/articles/redux-with-mark-erik...

Re: Idiomatic Redux: Implementation and Intent

#15

Post by forgottenacc57 »

acemarke wrote: post #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…

Perhaps redux really might benefit from communicating heavily with beginners.

Re: Idiomatic Redux: Implementation and Intent

#16

Post by acemarke »

forgottenacc57 wrote: post #15
acemarke wrote: post #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…

Perhaps redux really might benefit from communicating heavily with beginners.

Well, I do spend a ton of time answering questions from Redux beginners in many places online: Reactiflux, Stack Overflow, Reddit, etc. That's why my first contribution to Redux was writing the Redux FAQ [0], because I kept seeing the same questions being asked over and over. Ditto for the "Structuring Reducers" docs section as well [1]. So, I'd say I've got a pretty good idea what kinds of questions people are asking.

The docs themselves are written in a very "from first principles" style. For example, the page on "Middleware" starts by trying to show various ways to solve the problem of logging all actions, and iterates from "monkey-patching the store" up to a reusable system for wrapping `dispatch`. Some people find this approach very helpful, others don't. As Dan commented during the original development process:

> So hard to write the new docs. Many different audiences to cater to. Should make sense to: Flux beginners, FP people, FP people who don't get Flux, Flux people who don't get FP, normal JS people too. Flux people: “is this proper Flux?” FP people: “is this that weird thing called Flux?” Normal people: “why not Backbone”

Now, at this point, far more people are familiar with Redux than with "Flux", so perhaps the goal of making the docs understandable and relatable to Flux concepts isn't as important.

Most of my work around Redux has been improving the docs, writing my own tutorials and explanations on my blog (like this post), and answering people's questions elsewhere. I'm always happy to work with anyone who wants to help improve the Redux docs, and I'm totally open to suggestions and pull requests.

[0] http://redux.js.org/docs/FAQ.html

[1] http://redux.js.org/docs/recipes/StructuringReducers.html

Re: Idiomatic Redux: Implementation and Intent

#17

Post by acemarke »

sAbakumoff wrote: post #14

I don't event want to open the article that has both of "idiomatic" and "tao" words in the title.

For what it's worth, "Practical Redux" is my blog series that demonstrates Redux techniques by building a sample app. "Idiomatic Redux" is my series for my own thoughts on why I think certain Redux usage patterns are good or bad. The phrase "Tao of Redux" was just something that popped into my head and sounded catchy, and seemed to go along with the idea of "explaining the Redux philosophy".

Re: Idiomatic Redux: Implementation and Intent

#18

Post by cageface »

forgottenacc57 wrote: post #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…

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.

Re: Idiomatic Redux: Implementation and Intent

#19

Post by danenania »

cageface wrote: post #18
forgottenacc57 wrote: post #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…

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.
Post reply on HN