[tomelders]

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 can't imagine yet. I'm so tired of this short-sighted obsession with configuration some developers seem to have.

I think the author has a myopic vision for where Redux should go.

[badestrand]

> 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 reducer be an object with methods instead of a big switch function operating on string constants.

[adamsea]

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.

[thinkloop]

One of the original reasons for message passing is that multiple reducers can respond to the same action. There have been many libraries since the beginning that try to shrink that relationship (ex reducks), but I never understood it, my code is replete with multiple responders.

[badestrand]

> my code is replete with multiple responders

Thanks for your input! Do you mind giving 2-3 examples of good uses of multiple reducers for the same action?

[thinkloop]

One example is fetching data, often it is more effecient to request data in a certain way, but the app needs it represented differently, multiple reducers can respond to the same payload and take what they need.

Another example is url updates, I use state-driven-routing and when a url update happens many reducers need to respond to get the pieces of state they are concerned about.

Another example is a login status change, many reducers may need to update themselves if a user logs in our logs out.

It's the difference between having tons of highly specific 1:1 actions getting called from the action creator with their relationship to the root action obfuscated vs. having 1 action that many respond to with their relationship to that action clearly denoted.

To take it a bit further, it reminds me of refactoring vs adding another "if" statement - the former requires comprehensive understanding of the holistic purpose of the system with the dependent relationships properly defined (anti-fragile), whereas the latter is a temporary bandaid that can be implemented with less thought (and the sideeffects that come with it).

[mikewhy]

> when a url update happens many reducers need to respond

Wouldn't the components handle this change and dispatch any actions needed?

> a login status change, many reducers may need to update themselves if a user logs in our logs out.

Again, couldn't this be handled at the component level? It seems risky to have multiple sources of truth for data.

[thinkloop]

> multiple sources of truth

There wouldn't be more than a single source of a given truth, the multiple responders pull different truths relevant to them, the combination of which making the complete app state.

[tomelders]

Middleware. A UI events logger for example. Or finishing a network request may need to close some part of tge Ui and also trigger a reload somewhere else.

[zzzzzzzza]

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)

[badestrand]

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

[bpicolo]

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

[mezzode]

You can already write interfaces for your Redux actions in TypeScript to get the benefits of static typing, so I'm not even sure that there would be an appreciable improvement if Redux used methods instead.

[vosper]

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

[zzzzzzzza]

I feel like this benefit is more theoretical than practical owing to redux devtools, which offers a very similar experience of seeing what's been executed, perhaps even superior in some ways since you can see "everything" that's happening (with respect to the redux store), though you could probably create a similar thing without message passing

[SeeThruHead]

"In basically all cases every action is handled by exactly one reducer" this is patently false