Live data from Hacker News

Idiomatic Redux: Implementation and Intent

blog.isquaredsoftware.com

61–70 of 88 posts

Re: Idiomatic Redux: Implementation and Intent

#61
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…

My only criticism about these tools/addons is that you're multiplying your dependencies to solve an "issue" that could have been entirely avoided by choosing a state management design that is more suitable for the situation. Most developers default to Redux without acknowledging the costs to using it.

Shameless plug: I created React Axiom for those who want a lightweight model pub/sub render paradigm with React:

https://hackernoon.com/introducing-react-axiom-84bf37a50adb

https://github.com/wgoto/react-axiom

Re: Idiomatic Redux: Implementation and Intent

#62
post #43

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…

Another red flag on redux: recommended practice--query JSON over HTTP (likely backed by an RDBMS), renormalize the hierarchical data, and then reshape the renormalized data before passing to components.

Re: Idiomatic Redux: Implementation and Intent

#63
post #43

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…

[deleted]

Re: Idiomatic Redux: Implementation and Intent

#64

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.

> they're both very different

Yes, but they exist to solve very similar problems.

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

You may find it feels differently in practice. Because when I look at redux, I get reminded of managing crazy state trees in redux, and why I went to react/mobx in first place. :)

To be sure, Redux has strengths too, and there are tradeoffs. But I don't think that a brief "mobx looks like ember!" really conveys much, and I think the number of people who have been happy after switching from redux to mobx further undercuts such easy dismissals.

Re: Idiomatic Redux: Implementation and Intent

#65
post #60

Earlier quoted context omitted.

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.

This is utterly ridiculous. Mark is often found on, for example, the react subreddit helping out folk with redux problems, and it's not at all an efficient or practical way to gain a following. If he were focused on fame and glory, he'd do much better simply writing Medium articles to a large audience and spamming social media links.

These kind of comments are disappointing to read, especially when directed at someone sacrificing an awful lot of time helping others.

Re: Idiomatic Redux: Implementation and Intent

#66

Earlier quoted context omitted.

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.

My frustration wrt redux was organising the file structure where to place actions reducers. Otherwise it was a joy to work with. I considered it very simple and easy to work until I found mobx.

Re: Idiomatic Redux: Implementation and Intent

#67

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…

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.

Re: Idiomatic Redux: Implementation and Intent

#68

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]

Re: Idiomatic Redux: Implementation and Intent

#69

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.

It deserves to be first, because most people jump into redux because it seems like you're supposed to use it. Also I don't think I agree with the claim that they are very different. In theory, yes. In practice, I use it to solve the same problems in generally the same way (action driven updates, one-way data flow rendering), but with less boilerplate and (for my use cases) better performance. YMMV is fair, but anyone doing serious react work should be at least familiar with both.

Re: Idiomatic Redux: Implementation and Intent

#70

Earlier quoted context omitted.

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.

My frustration wrt redux was organising the file structure where to place actions reducers. Otherwise it was a joy to work with. I considered it very simple and easy to work until I found mobx.

The two typical approaches are "file-type-first" (separate folders for "actions", "reducers", "containers", etc), and "feature-first". I've got articles discussing various React/Redux project structure approaches at https://github.com/markerikson/react-redux-links/blob/master... .
Post reply on HN