Hacker News Reader

Comment by krishanath | Hacker News Reader

So what is the problem solved by Redux? I don't see a simple explanation of that in your write up. Most people struggle when asked this question. Some people go on about "time travel" and other fancy things that have nothing to do with the business problem you're trying to solve. Other people talk about "single source of truth" as if that didn't exist before Redux.

View on HN

The problem is people creating different data architectures on every single project they create.

Redux specifies a unidirectional data flow with a single source of truth. And then it gives you very detailed tooling with which to debug this, and an ecosystem of middlewares to augment the incredibly basic/boilerplatey API either to simplify logic or to add extra features (for example, analytics).

Writing this from my phone so I cannot be as verbose as I want to be.

I can not speak for every case, so I will talk about why I sometimes use it in React:

First off, there is a synergistic effect where React handles data coming from above in the hierarchy, which Redux facilitates.

Secondly, it can be very hard to keep track of what components are handling what logic in large applications so having it abstracted away in an easy to test way is considered a win for many.

That is the good overview I feel, there's also that popular Dan Abramov medium post[0] that deals with it. I do believe redux is overused, and people would benefit from weighing whether simple react is good enough for a project, buy I understand the risk you feel you take on if the scope runs away and suddenly you need to do a costly migration to redux later on in the project where it can be a lot harder to do so.

[0] https://medium.com/@dan_abramov/you-might-not-need-redux-be4...

This was a really long article so you may probably missed my reasoning for using redux. I'm copying from the "Introduction to redux section" (which comes right after the "Introduction"):

"I have to say that I got interested in redux because of all that buzz this framework generated. However, I got really interested in it when I understood how close its philosophy was to functional programming - this, when combined with the usage of react functional components will enable you to write great code and (most important for me) really enjoy coding with it [...]"

So, for me the reason for using redux is its functional programming related philosophy. Ofcourse there are other js frameworks that are more functional (in the fp meaning of the word functional) like hyperapp, choo and definitely many others I'm not aware of but most of them built on the concepts of react functional components and redux, and redux is much more popular.

Sorry, to me that's an unsatisfying answer. You are not saying what problem redux is solving for you. "It is like functional programming" does not even attempt to explain what the problem being solved is.

To answer the "functional programming" aspect:

First, "pure functions" are generally agreed to be easier to test and easier to understand, because they only rely on their inputs, and don't modify anything outside of the function. In a real application of any kind, you realistically can't write the entire app as pure functions. But, writing more of your codebase as pure functions means more of it is easily testable and understandable overall.

Second, while the OOP vs FP debate is never-ending, FP does lead to some nice forms of reusability via composition.

With Redux, you are intended to write your "reducers" as pure functions. It's up to you whether those reducers have complex logic or simply return the values they were given in the actions, but the reducers (which control the actual state updates) should all be pure, and therefore easily testable and understandable. Reducers can also be composed together to add new behaviors, such as:

    const finalUsersReducer = undoable(resettable(originalUsersReducer));

In addition, writing pure functions with no side effects, in conjunction with dispatching plain object actions, is what makes Redux's time travel debugging feasible. (That's not to say it's impossible to implement time travel in other ways, just that those aspects of Redux's design make it very straightforward to implement time travel.)

One benefit is that you have explicit events that create specific state changes. Your app is a succession of these events that certainly help when debugging and thinking about the potential states your app can be in.

Like other state management solutions, it also 'writes' all your shouldComponentUpdate methods for you.

Sounds like event sourcing, for ui.

There's been many comparisons made to event sourcing, but the actual semantics of the dispatched actions are up to you. You might dispatch `USER_LOGGED_IN`, or you could dispatch `SET_USER_LOGGED_IN_STATUS` (ie, "past-tense event that occurred" vs "present-tense imperative set some state"). Redux doesn't care how you name your actions. There's been lots of arguments over how action semantics should be viewed. I recapped some of the discussion in my post 'The Tao of Redux, Part 2 - Practice and Philosophy" ( http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao... ).

Sure, with event sourcing there is another level of difference between commands, query, events. But the similarity is there.

Reply on news.ycombinator.com