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

71–80 of 88 posts

Re: Idiomatic Redux: Implementation and Intent

#71

Post by acemarke »

Jare wrote: post #57

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 reduc…

Missing a bit, yeah.

It's entirely possible that the `commentsReducer` does know how to handle all relevant actions. It's also possible that it only needs that extra data for one specific action.

One of the biggest advantages of the "reducer" concept is that _they're just functions_, and you can mix, match, and combine them in any way that works for you. I show several examples of additional custom reducer structures in the "Structuring Reducers - beyond `combineReducers`" [0] section of the Redux docs, and also in my blog post "Practical Redux, Part 7: Feature Reducers" [1].

As a quick summary, instead of having the `combineReducers`-generated function as your root reducer, you can further wrap that up in other functions, such as one that takes an array of reducers and runs them in sequence, or one that only does that special handling for a specific action case and otherwise delegates all handling to the normal `combineReducers` approach.

[0] http://redux.js.org/docs/recipes/reducers/BeyondCombineReduc...

[1] http://blog.isquaredsoftware.com/2017/01/practical-redux-par...

Re: Idiomatic Redux: Implementation and Intent

#72

Post by learc83 »

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…

There is no way you're maintaining anything more than trivially complex apps like this.

It was never built to be used that way. Passing down chains of attributes and functions through 5+ layers isn't idiomatic React because React was created with Flux in mind--this is not the intended methodology.

>If you're having difficulty moving components around because of state consider that you may be thinking too statefully and should try to find a less stateful way to describe your UI

That is a meaningless platitude. State exists, you can't remove it. No matter how much you minimize it, you're going to eventually end up passing props down through an arbitrarily large number of layers if you have no state management system in place.

Language designers realized this was a problem decades ago--it's why we have scoping rules. Passing down chains of arguments through layers and layers of functional calls is unwieldy. And it's worse when each one of these functions is directly producing user output.

Re: Idiomatic Redux: Implementation and Intent

#73

Post by ng12 »

cloverich wrote: post #69
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.

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…

But it's a little ridiculous when you can't even mention Redux without MobX being dropped.

Also an important thing to note is that Redux is fundamentally designed to lend itself to one-way data flow with a well-abstracted barrier between global state and your components. Yes, you can use MobX to accomplish the same thing but the pattern is fundamentally less obvious especially for someone new to React.

Re: Idiomatic Redux: Implementation and Intent

#74

Post by acemarke »

qudat wrote: post #56

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 wit…

I have links to a number of useful utilities for visualizing when and why components re-rendered in the "DevTools#Component Update Monitoring" section of my Redux addons catalog [0]. Hopefully those help.

I'm a bit curious why you say that "reselect makes it less clear when things are being re-rendered". The overall reasons shouldn't change - connected components will re-render when values from `mapState` or props from the parent component have changed by reference.

Thunks are definitely the "minimum viable approach" for handling async logic in Redux, or at least the minimum _suggested_ approach (as opposed to doing async handling purely inside of a component). I agree that sagas (and observables) are a pretty big jump for most devs to make, but then again, async logic in general is more difficult to reason about. Personally, I still think most devs should use thunks until they see a need for something else (per my post "Idiomatic Redux: Thoughts on Thunks" [1]).

Redux does deliberately push the question of "how do I handle async logic?" outside of its core, and leave it up to you. That's both because Redux focuses on structuring synchronous state updates, and because (per my post) Dan and Andrew wanted to give devs flexibility in what specific technique they use for handling async.

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

[1] http://blog.isquaredsoftware.com/2017/01/idiomatic-redux-tho...

Re: Idiomatic Redux: Implementation and Intent

#75

Post by saosebastiao »

I'm infinitely more comfortable with functional composition over object composition, but Mobx is still far more intuitive to me. It's because functional composition over a constantly changing global state tree is a huge fucking mess. There's a reasonably objective explanation as to why it is a mess, and more specifically, why Redux suffers from so much boilerplate and painful refactorings.

In UI programming you are managing state, full stop. Almost any UI can be described as a state machine. Not just GUIs, but any UI: digital, analog, mechanical, whatever. And since you are basically managing state machines, any refactoring of the functionality of your UI is fundamentally a refactoring of your state. Rendering is a functional refactoring (state doesn't change), but if you are building a UI and not just a simple landing page, you are far more likely to refactor functionality over rendering...meaning your data is more likely to change than your functions. In other words, UI programming via functional composition over a frequently changing global state tree falls on the wrong side of the Expression Problem [0].

Every time you change your data, you have to modify every functional pipeline, from beginning to end, that touches that changed section of your state tree. That is where all the boilerplate comes from, and that is why Redux is consistently criticized as a system that becomes more and more unwieldy as your UI complexity grows. It is a bad abstraction for the problem at hand.

Mobx is a far better pattern IMO, and I feel entirely comfortable saying that is an objective position to take as long as your functionality is more likely to change than your rendering. It isn't that Mobx is a superior idea, it's just the fact that it embraced object composition for a use case that is perfect for it.

[0] http://wiki.c2.com/?ExpressionProblem

Re: Idiomatic Redux: Implementation and Intent

#76

Post by cloverich »

ng12 wrote: post #73
cloverich wrote: post #69

Earlier quoted context omitted.

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…

But it's a little ridiculous when you can't even mention Redux without MobX being dropped. Also an important thing to note is that Redux is fundamentally designed to lend itself to one-way data flow with a well-abstracted barrier between global state and your components. Yes, you can use MobX to accomplish the same thing but the pattern is fundamentally less obvious especially for someone new to React.

> But it's a little ridiculous

That's the point I'm contending: Its not ridiculous because its not obvious that its an alternative. And not just an alternative, but a much much simpler alternative for many use cases. I absolutely agree its annoying, and I'll have to be that annoying guy for a while. Because I can't stand seeing people spend time on clever solutions to problems that, with mobx, you may not have.

Re: Idiomatic Redux: Implementation and Intent

#77

Post by ng12 »

cloverich wrote: post #76
ng12 wrote: post #73

Earlier quoted context omitted.

But it's a little ridiculous when you can't even mention Redux without MobX being dropped. Also an important thing to note is that Redux is fundamentally designed to lend itself to one-way data flow with a well-abstracted barrier between global state and your components. Yes, you can use MobX to accomplish the same thing but the pattern is fundamentally less obvious especially for someone new to React.

> But it's a little ridiculous That's the point I'm contending: Its not ridiculous because its not obvious that its an alternative. And not just an alternative, but a much much simpler alternative for many use cases. I absolutely agree its annoying , and I'll have to be that annoying guy for a while. Because I can't stand seeing people spend time on clever solutions to problems that, with mobx, you may not have.

You'd have a point if the article was intended for people trying to bootstrap a React stack but this is specifically a deep-dive on Redux. It's equivalent to people proselytizing Rust in any thread that mentions Go. Believe it or not some of us are not ignorant -- we know what MobX is and still choose Redux every time.

Re: Idiomatic Redux: Implementation and Intent

#78

Post by [deleted] »

cloverich wrote: post #76
ng12 wrote: post #73

Earlier quoted context omitted.

But it's a little ridiculous when you can't even mention Redux without MobX being dropped. Also an important thing to note is that Redux is fundamentally designed to lend itself to one-way data flow with a well-abstracted barrier between global state and your components. Yes, you can use MobX to accomplish the same thing but the pattern is fundamentally less obvious especially for someone new to React.

> But it's a little ridiculous That's the point I'm contending: Its not ridiculous because its not obvious that its an alternative. And not just an alternative, but a much much simpler alternative for many use cases. I absolutely agree its annoying , and I'll have to be that annoying guy for a while. Because I can't stand seeing people spend time on clever solutions to problems that, with mobx, you may not have.

[deleted]

Re: Idiomatic Redux: Implementation and Intent

#79

Post by [deleted] »

cloverich wrote: post #76
ng12 wrote: post #73

Earlier quoted context omitted.

But it's a little ridiculous when you can't even mention Redux without MobX being dropped. Also an important thing to note is that Redux is fundamentally designed to lend itself to one-way data flow with a well-abstracted barrier between global state and your components. Yes, you can use MobX to accomplish the same thing but the pattern is fundamentally less obvious especially for someone new to React.

> But it's a little ridiculous That's the point I'm contending: Its not ridiculous because its not obvious that its an alternative. And not just an alternative, but a much much simpler alternative for many use cases. I absolutely agree its annoying , and I'll have to be that annoying guy for a while. Because I can't stand seeing people spend time on clever solutions to problems that, with mobx, you may not have.

[deleted]

Re: Idiomatic Redux: Implementation and Intent

#80

Post by [deleted] »

cloverich wrote: post #76
ng12 wrote: post #73

Earlier quoted context omitted.

But it's a little ridiculous when you can't even mention Redux without MobX being dropped. Also an important thing to note is that Redux is fundamentally designed to lend itself to one-way data flow with a well-abstracted barrier between global state and your components. Yes, you can use MobX to accomplish the same thing but the pattern is fundamentally less obvious especially for someone new to React.

> But it's a little ridiculous That's the point I'm contending: Its not ridiculous because its not obvious that its an alternative. And not just an alternative, but a much much simpler alternative for many use cases. I absolutely agree its annoying , and I'll have to be that annoying guy for a while. Because I can't stand seeing people spend time on clever solutions to problems that, with mobx, you may not have.

[deleted]
Post reply on HN