When you're just dealing with functions and data, I don't know how it could get more simple. I know that it has made my code much more readable, testable, and organized.
Immutability certainly makes it less harmful, but it still means that a function in one area of the codebase can modify the global state and affect a completely different area of the codebase.
Atomicity is basically a meaningless buzzword in this situation, given JavaScript doesn't have parallelism.[1]
> When you're just dealing with functions and data
When you're just dealing with functions and data, you aren't using Redux, so really anything you have to say after that isn't relevant.
At the end of the day, you can make all these mistakes yourself if you want, but you'd be better served by listening to the programmers of the past and learning from their mistakes instead.
[1] What you're actually talking about is the fact that the entire transition is executed in the same event, which isn't the same thing as atomicity, but is actually somewhat useful because it works around the horrible things JS programmers often do that make it difficult to tell what order state transitions will be executed in, despite being in a single-threaded environment. However, the fact that it enables inserting state transitions into utterly untraceable code is hardly a point in Redux's favor if you want your code to be traceable in the first place.
And no, it's not "untraceable code". Redux is explicitly meant to make it much easier to trace when, where, why, and how your state has been updated. All state changes happen via reducer functions (not random pieces of code somewhere in your UI logic), and the state updates themselves can be viewed using the Redux DevTools (which can now even give a stack trace for every individual dispatched action).
Which are called where?
> and the state updates themselves can be viewed using the Redux DevTools (which can now even give a stack trace for every individual dispatched action).
So now we've added a second tool to fix the problem caused by the first tool.
All interactions revolve around "dispatching" an action to the store. The root reducer function is called as part of that `dispatch()` sequence. This gives a central point that allows tracing the resulting state changes:
store.dispatch({type: "INCREMENT"})
This isn't "fixing a problem" with Redux, this is a core designed capability to allow you to understand how your app is behaving.
You're saying I can't modify global state and have effects on a completely different area of the code, but I'm saying, yes, you can. All you're doing is telling me about the fairly-pointless layers of indirection Redux adds. Adding a layer of indirection doesn't solve the problem.