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