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

31–40 of 88 posts

Re: Redesigning Redux

#31

Post by Waterluvian »

agentultra wrote: post #22

> You don’t need to understand what a “comonad” is to use jQuery, and you shouldn’t necessarily need to comprehend functional composition to handle state management. Is there a point to spreading this piece of sage FUD? It should not be surprising that pure functions + immutable state results in fewer errors. The "pattern" Redux asks you to use prevents you from shooting your leg off. If you've written a sizeable app…

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

Re: Redesigning Redux

#32

Post by agentultra »

Waterluvian wrote: post #31
agentultra wrote: post #22

> You don’t need to understand what a “comonad” is to use jQuery, and you shouldn’t necessarily need to comprehend functional composition to handle state management. Is there a point to spreading this piece of sage FUD? It should not be surprising that pure functions + immutable state results in fewer errors. The "pattern" Redux asks you to use prevents you from shooting your leg off. If you've written a sizeable app…

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!

Re: Redesigning Redux

#33

Post by zzzzzzzza »

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…

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)

Re: Redesigning Redux

#34

Post by senoroink »

This article resonated with me fairly well. As someone who has had an extensive background in Rails and has more recently switched to 100% javascript, this kind of pattern is what the community needs. There's something to be said about getting up and running as quickly as possible. Sure you can make the argument that not everyone's application is the same, but there's a ton of similar patterns that would have been better suited to having less mental gymnastics with a simple config while still leaving the door open with FP for those that want to fine tune.

Re: Redesigning Redux

#35

Post by myguysi »

Isn’t one of the points of redux to decouple actions from reducers? How would you implement multiple reducers responding to a single action if your actions are tied to a reducer with a namespace?

Re: Redesigning Redux

#36

Post by bpicolo »

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)

> to an object with methods would bring any benefits

It lets static typing do a lot more work for you when using Typescript/Flow. Less to remember and less to break.

Message passing is a really useful architectural choice because it lets you do powerful global operations. It's a lot crummier on the development ergonomics front.

Re: Redesigning Redux

#37

Post by methyl »

myguysi wrote: post #35

Isn’t one of the points of redux to decouple actions from reducers? How would you implement multiple reducers responding to a single action if your actions are tied to a reducer with a namespace?

This can be done using Subscriptions [1].

I have another problem with this library, which is relying on singleton pattern for communication. This way, you cannot have more than one rematch instance in one application, which can be limiting. It also makes reasoning more difficult.

[1] https://github.com/rematch/rematch/blob/master/plugins/subsc...

Re: Redesigning Redux

#38

Post by kenforthewin »

Is Redux too complex? That's the central argument this article makes but I find it to be patently false. What drew me to redux was its simplicity: Abramov said from the beginning that it's not anything you can't code yourself, it just provides a thin framework around making changes to some base state object. Its main strength (to me) is that it forces developers to think about state changes as mutations rather than recreating a spaghetti state machine oneself.

Re: Redesigning Redux

#39

Post by [deleted] »

myguysi wrote: post #35

Isn’t one of the points of redux to decouple actions from reducers? How would you implement multiple reducers responding to a single action if your actions are tied to a reducer with a namespace?

[deleted]

Re: Redesigning Redux

#40

Post by vosper »

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)

Direct function calls would at least make it easier to step through the code in the debugger, I imagine.
Post reply on HN