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

Redesigning Redux

medium.com

Post reply on HN
Print view View original

41–50 of 88 posts

Re: Redesigning Redux

#41

Post by bengillies »

randomdata wrote: post #24
bengillies wrote: post #20

Earlier quoted context omitted.

The problem with putting all async code directly into components is that often, async code is business logic or some other non-view-layer thing that doesn't really belong in a component. The benefit of redux-thunk (and there are obviously other alternatives that provide the same value) is that it lets you write plain functions that have nothing to do with the store, and nothing to do with components. If you put all y…

> async code is business logic or some other non-view-layer thing that doesn't really belong in a component. In many React applications, components are separated into independent "controller"-layers and "view"-layers (containers and components are nomenclature I see occasionally, but the important takeaway is that both inherit from the React component class). Business logic has no place in your view components, of co…

> Business logic has no place in your view components, of course, but is quite appropriate in your controller components.

Sure. Where you actually put stuff depends entirely on the complexity of what it is that you're building. If you have an async function that you need to use in several places then it makes sense to keep it separate. If you have several of these then maintaining a separate container component for each view component that needs access to these quickly becomes unmaintainable.

On the other hand, keeping them as separate functions and adding them in via redux `connect` syntax and `mapDispatchToProps` is simple and makes it clear what's going on. In this scenario, the `connect` higher-order-component acts like the container class, but it built up from separate parts depending on what you need.

> redux-thunk seems to encourage that you use it for everything

I don't think this is true. redux-thunk is a piece of middleware and that's pretty much it. It should be used however is most appropriate for your application and your particular use case. Keeping state inside components isn't always appropriate, but isn't always a bad thing either. If one is growing too complicated, then perhaps the other is more appropriate.

Re: Redesigning Redux

#42

Post by chncdcksn »

(To preface, I use React/Redux in all of my web applications. I think Redux is great for managing state.)

One thing I’ve never quite understood about Redux is why we are dispatching pure data instead of a function of state. This would remove the need for reducers, since your action _is_ your reducer. Something like this...

https://gist.github.com/anonymous/a5d741c5dec81be61e0aa70820...

Would this come with any drawbacks? I could see a large application having performance issues because of a large number of function allocations, but for small applications I don’t see a downside, just a simpler API.

Re: Redesigning Redux

#43

Post by bpicolo »

chncdcksn wrote: post #42

(To preface, I use React/Redux in all of my web applications. I think Redux is great for managing state.) One thing I’ve never quite understood about Redux is why we are dispatching pure data instead of a function of state. This would remove the need for reducers, since your action _is_ your reducer. Something like this... https://gist.github.com/anonymous/a5d741c5dec81be61e0aa70820... Would this come with any drawba…

Now what you have is a global mutable state store instead of an "immutable" state store, as everywhere can change anything and tracking down what code does what is back to being nightmarish.

Re: Redesigning Redux

#44

Post by vanderZwan »

> Is Redux more performant? No. In fact, it gets slightly slower with each new action that must be handled.

This point is not revisited. What is the performance of Rematch in comparison to Redux? I mean I guess it's more or less the same, since it's essentially Redux with less boilerplate, but it would be nice to have an explicit answer to this.

Re: Redesigning Redux

#45

Post by adamsea »

badestrand wrote: post #27
tomelders wrote: post #9

The strength of redux is that all your interactions with it are through functions. Redux today is far better than the Redux of yesteryear thanks to things like ReSelect, Thunks, Sagas, Higher Order Components etc. All these things augment Redux, and they can do so because of Redux's open embrace of the humble pure function. Once you commit to a config based approach, you're basically closing the door to a future you…

> The strength of redux is that all your interactions with it are through functions I think it's the other way around: The greatest weakness of Redux is that (unnecessarily) message passing instead of function calls are used. Why do a `store.dispatch({type: 'INCREMENT', value: 10})` when it could be a `store.count.increment(10)`? In basically all cases every action is handled by exactly one reducer so just let the re…

If the verbosity bothers you, why not write a helper function for your codebase? Action creator functions originally served this role, and you can successfully create more complex "helper" functions for generating unique action type names, sets of action creators, or even reducers if you have a consistent use-case.

IMHO you want the tools you use (i.e. redux) to be flexible and powerful, and write helpers, etc, to increase your ease-of-use. Otherwise, as the OP said, you're unnecessarily restricting yourself and creating a more difficult future.

Re: Redesigning Redux

#46

Post by ballenf »

mpfundstein wrote: post #8
heygrady wrote: post #3

Rematch reminds me of Marty.js. I like some of the ideas about providing a createStore wrapper that is more zero-config and using something like redux-actions to make reducers simpler. I have been using my own wrapper around sagas to allow for dispatching effects. They lose me with their idea of "models" where I have a global dispatch that can be extended, like dispatch.modelName.actionName. That's just old school ob…

whats the problem of mixing the good parts of OOP with the good parts of FP?

The two are just so fundamentally different that you will usually end up with a net negative taking two good things from both worlds. With the parent comment, you lose a degree of composability of the functional world while not gaining any degree of inheritability from OOP.

Re: Redesigning Redux

#47

Post by badestrand »

zzzzzzzza wrote: post #33
badestrand wrote: post #27

Earlier quoted context omitted.

> The strength of redux is that all your interactions with it are through functions I think it's the other way around: The greatest weakness of Redux is that (unnecessarily) message passing instead of function calls are used. Why do a `store.dispatch({type: 'INCREMENT', value: 10})` when it could be a `store.count.increment(10)`? In basically all cases every action is handled by exactly one reducer so just let the re…

I missed the part where you explained why changing the reducer to an object with methods would bring any benefits, or what's bad about message passing (it seems to me off the top of my head that changing this would at the very least, break redux observable as it currently works)

> I missed the part where you explained why changing the reducer to an object with methods would bring any benefits

Because this is how the rest of your programming works, you call functions. In Node you don't have `fs.processMessage('readFile', {path, next})` because `fs.readFile(path, next)` is simpler. Message passing is nice if you pass process boundaries or can't know about the function definition but in Redux you pull in the string constants and everything anyway. Message passing also lets you hook several handlers (reducers) to the same message but I have yet to see it significantly used, this is a niche case.

Re: Redesigning Redux

#48

Post by Waterluvian »

agentultra wrote: post #32
Waterluvian wrote: post #31

Earlier quoted context omitted.

Coming from no math background I LOVE functional programming and would love to learn what words I'm using have existing math terms.

A functional programming rosetta stone? Sounds challenging and interesting!

Hah. I just meant maybe a blog post that maps the terms I use in JavaScript land with math land. Ie. "it's not a reducer it's a functormonadicfoobar"

Re: Redesigning Redux

#49

Post by randomdata »

bengillies wrote: post #41
randomdata wrote: post #24

Earlier quoted context omitted.

> async code is business logic or some other non-view-layer thing that doesn't really belong in a component. In many React applications, components are separated into independent "controller"-layers and "view"-layers (containers and components are nomenclature I see occasionally, but the important takeaway is that both inherit from the React component class). Business logic has no place in your view components, of co…

> Business logic has no place in your view components, of course, but is quite appropriate in your controller components. Sure. Where you actually put stuff depends entirely on the complexity of what it is that you're building. If you have an async function that you need to use in several places then it makes sense to keep it separate. If you have several of these then maintaining a separate container component for e…

I agree that no two applications have the same needs, but async functions (and non-async, for that matter) are naturally separate and reusable, so I'm not sure I am entirely clear on what you are getting at here. What is the benefit of using connect to connect your function and simply calling that function from your controller? Code needed in multiple places should not require redux.
Post reply on HN