Exactly. I ported something I wrote in angular to react+redux. The angular version was super short and worked most of the time, but I had a bunch of weird stat

Exactly. I ported something I wrote in angular to react+redux. The angular version was super short and worked most of the time, but I had a bunch of weird state/race conditions/display issues I could never resolve. Porting it to redux meant: Wire up the reducer with enough initial state containing dummy data so render() works correctly. Add buttons that dispatch actions. Use the debug tools to verify that the proper action gets logged. If it's an action like `LOAD_EXAMPLE` verify that `example` contains the expected name of the example. Once the action is being logged properly handle it in the reducer. Use the debug tools to verify that the state is being changed as expected. At this point the feature should be working. old state -> action dispatched -> reducer -> new state. Having things separated like this means that you only ever have 3 kinds of issues: 1) The wrong action is being raised. Solution: Fix the event handlers or the action generator that calls dispatch. If the action is wrong no need to look elsewhere. 2) The reducer is returning the wrong new state. Solution: Fix the reducer. If the action was right and the new state is wrong, the reducer is the problem. 3) The app is rendering wrong. Solution: Fix the component. If the new state was correct but things look wrong, the only possible place the problem can be is the component. Is this verbose? YES! Is this complicated? NO! It's a lot of very simple javascript functions that do one thing at a time.