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

51–60 of 88 posts

Re: Idiomatic Redux: Implementation and Intent

#51

Post by mweststrate »

te_chris wrote: post #39
hesarenu wrote: post #22

Earlier quoted context omitted.

Mobx is an alternative. Simple and less boilerplate.

This comment is always the first, every time, but they're both very different. Mobx is mutable binding, redux is one way, functional data flow. They have their tradeoffs, but when I look at mobx I get reminded of managing crazy state trees in ember and why I went to react/redux in the first place. YMMV.

> I look at mobx I get reminded of..

Looking like, and being like are two different things :) Mobx reminds people (rightfully) of Meteor, Knockout, Angular etc, but when working with it you will see it is quite a different best. Just like Redux will remind people of flux, but that doesn't mean people shouldn't try Redux because e.g. Facebook Flux didn't work out.

Re: Idiomatic Redux: Implementation and Intent

#52

Post by [deleted] »

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

Mobx is an alternative. Simple and less boilerplate.

[deleted]

Re: Idiomatic Redux: Implementation and Intent

#53

Post by ngsayjoe »

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…

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.

Re: Idiomatic Redux: Implementation and Intent

#54

Post by CuriousSkeptic »

hesarenu wrote: post #48
te_chris wrote: post #39

Earlier quoted context omitted.

This comment is always the first, every time, but they're both very different. Mobx is mutable binding, redux is one way, functional data flow. They have their tradeoffs, but when I look at mobx I get reminded of managing crazy state trees in ember and why I went to react/redux in the first place. YMMV.

The crazy state tree in redux is what made me go to mobx. I had events firing off updating multiple redux functions. It was very difficult to understand the flow. Mobx has simplified my changes to one place. To me they both the same managing client side state.

Mobx vs redux is probably not the right comparison here though. Mobx comes bundled with 'computed' and encourages most state to be handled there.

Redux doesn't have this, instead libs like reselect fills space.

My experience with redux was frustrating in the way you explained, but once I "got" how to defer all state to reselect instead of trying to do things with reducers it got significantly simpler.

Re: Idiomatic Redux: Implementation and Intent

#55

Post by qudat »

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

I actually find it easier to reason about my components when I can trace data sharing in my hierarchy rather than allowing components to cheat and circumvent sharing state in their common ancestor. I think it's idiomatic React to construct hierarchies of functional components topped by very few stateful components. Using connect() to turns components deep in the hierarchy into stateful components can only lead to a l…

I get what you're saying but for large react applications using Redux helps to dramatically reduce state complexity and increase maintainability.

Having one function 5 levels deep that receives its props from a top level function means everytime you add a prop you have to modify 5 function signatures to get that new data. That quickly becomes unsustainable when you have 10+ layers.

What happens when you want to modify the prop that is set in the parent? You have to pass through a callback function that will modify that parent props and then trigger a re-render.

Very quickly you end up with problems that flux/redux/mobx try to solve.

Re: Idiomatic Redux: Implementation and Intent

#56

Post by qudat »

I use react/redux for a very large application and overall it has been a powerful, robust, and scalable solution that handles 99% of our use-cases.

The biggest problem I struggle with is knowing when components rerender. Libraries like reselect that memoize state-composed functions really help with performance, but make it less clear when things are being rerendered and why they are being rerendered.

I also agree with some of the posts here that handling async actions, or side effects, can be rather difficult in the redux model. Redux-thunk is still being recommended even though Dan created it more as a bandaid solution rather than something more robust. We solved it with redux-saga, but my colleagues -- experienced developers -- struggled initially to grasp generators. I also think sagas run into the same problem that one action triggering multiple reducers has which is you could inadvertently trigger an action that hits one or more sagas and not realize you are causing side effects that you did not intent. I know there have been countless discussions on what to do about this problem, but I fear the solution will always be outside of the scope of the core library because of backwards-compat.

Re: Idiomatic Redux: Implementation and Intent

#57

Post by Jare »

The article does a great job of presenting Redux and stripping the "magic" out of it. But the section about dependencies between reducers bugs me A LOT.

"If a CommentsStore needed data from a PostsStore to properly update itself, it could call PostsStore.waitFor() to ensure that it would run after the PostsStore updated. [...] with Redux, that sequencing can simply be accomplished by explicitly calling specific reducer functions in sequence."

And it introduces a specific call order of slice reducers, and 'hasCommentReallyBeenAdded' variable, inside the root reducer to implement that dependency.

But it looks to me like such a dependency will usually be specific to a certain action, and in a modestly complex application, different actions will have dependencies in different orders, with different ordering and information needs, and moving those into the root reducer doesn't scale beyond one (i.e. the shown example). Thus, as is, the section doesn't really provide a useful pattern for building real apps. Those will need a different approach - represented by the catch-all but not so useful "it's all about how you want to write it."

Am I missing something about that section and topic?

Re: Idiomatic Redux: Implementation and Intent

#58

Post by k__ »

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

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.

Re: Idiomatic Redux: Implementation and Intent

#59

Post by shados »

weq wrote: post #43
acemarke wrote: post #31

Earlier quoted context omitted.

Well, _I_ am the author, _and_ a Redux maintainer, _and_ I've spent a ton of time discussing and using Redux :) I can legitimately say I'm _an_ expert on Redux, its implementation, and its use. The original point of writing it is that I see many people complaining about things like "having to use action creators" and "having to edit many files", when Redux itself doesn't actually require you to do those things. So ye…

The problem with redux is actually the dev-tools (and the ecosystem that spawned from the middleware). the newbies get wowed by "time travel debugging" and want to copy/paste there way to the $$$profit. Redux takes a simple concept, and turned it into something thats really hard to apply to the projects these people are writing; by reinventing words into a propriety language.... No one talks about about there state a…

The domain model is technically not anemic. It just uses more functional patterns. Using lenses/selectors to manipulate state instead of using OOP principles, as is common in FP languages. In the same groups talking about reducing an event log is fairly common too. Possibly more common would have been to call it "fold" I guess, but that's essentially a synonym.

As to your other point, you're right, and it is somewhat of an issue: Redux does work better when it's thought of as event sourcing. And it can (and IMO should) be used as one. When actions are nearly 1:1 with what is happening in the system, and you're simply doing a "fold" on the event log to then project it to a stateless UI, it works beautifully.

Re: Idiomatic Redux: Implementation and Intent

#60

Post by shados »

sAbakumoff wrote: post #37
acemarke wrote: post #31

Earlier quoted context omitted.

Well, _I_ am the author, _and_ a Redux maintainer, _and_ I've spent a ton of time discussing and using Redux :) I can legitimately say I'm _an_ expert on Redux, its implementation, and its use. The original point of writing it is that I see many people complaining about things like "having to use action creators" and "having to edit many files", when Redux itself doesn't actually require you to do those things. So ye…

IMHO experts who want to help people differ from self-proclaimed gurus who want to enlighten people. David Robinson ( data scientist not a basketball player) is the example of the first type. Take a look at his blog. He does not make any pretentious title or something, yet his articles are truly enlightening and influence millions of people!

It's no real secret that the author is a sucker for attention. I've always kind of felt that it was the first goal, and that he happened to help people was kind of a nice side effect.

From spamming his links everywhere he can, to begging for upvotes on Twitter, going by posting stuff about how he got famous and constant bragging, it's not new.

Post reply on HN