TL;DR: I just released Redux DevTools Extension v2.7, which brings “pausing” and “locking” features to improve the way of developing and debugging Redux apps. As a consequence, extension’s store enhancer is being deprecated.

Hot Reloading with Time Travel helps to boost the developer’s productivity significantly and makes the development fun. It could be more powerful visual alternative to TDD. However, you might not taking advantage of its full potential:

I never got to implementing the real workflow I imagined, so “Revert / Commit” buttons at the top only hint at it in a non-friendly way. Here’s how I imagined it. Say I’m working on a feature that involves complex local state transformations in response to user actions. In the last app I was working on, there was a drag-and-drop post editor with nested entities, handling of async responses, etc. Say I want to add a new type of post content. I added a button that dispatches an action but there is no handler so it’s a no-op now. I press “Record” and perform a few actions. Some of them may already be handled by reducers, some may not. Then I press “Stop”. Now DevTools enters a “loop” mode. It ignores any other actions in the app. I can’t interact with UI in my app. I’m focused on one scenario. Now I work on the reducer code. When I save a file, DevTools replays my “scenario” and shows computed states. I can switch between steps. I know that no stray AJAX request will mess up my state, that everything is completely predetermined by the scenario (actions) I recorded. I keep editing my reducers and see how that affects the computed states of the whole scenario. Runtime errors are displayed inline. Most likely, I will mess up some existing handlers while adding new feature — since scenario includes other actions, I will notice and fix it. Finally, the whole scenario is correct. Every computed state looks good, and UI looks good with every state. Now I can reorder actions right in DevTools to make sure that I don’t have weird race conditions. If I have any, I can keep fixing reducers. Finally when I’m ready, I exit the “loop mode”. I can work on the next feature or tweak the UI. And I can “save” the scenario to unit tests.

As Dan Abramov stated, some pieces are missing here. I’m implementing them in Redux DevTools Extension v2.7, though not exactly as described above. Basically, the “loop mode” is split into “pausing” and “locking”.

Pausing the recording of dispatched actions

In a real-world app usually there are tons of actions dispatched, and you can easily get lost in the recorded history. For such cases Redux DevTools becomes pretty useless. The solution would be to have a Pause button:

When the button is toggled, Redux DevTools instrumentation will not record the other actions, so you can work with just the current history, but still recomputing the future states:

While pausing, you can still time travel, skip and recompute actions. Also you can add new actions explicitly, just click Dispatcher, and dispatch even action creators (specified in actionCreators option):

If you click Commit (before or after pausing), only the current state will be stored. So it will also solve the memory issues, caused by storing large action’s payloads and states, especially when profiling the performance.

You can easily export the recorded history for a specific feature or generate tests for it.

Locking non-explicit changes

Usually it’s not enough just to pause the recording, we also want to forbid dispatching of other new actions. So we could focus on a specific feature we’re developing and, whenever we change something in the code, hot-reloading will recompute only the actions before locking without any additional requests. Just click the Lock button:

Unlike pausing, here we’re freezing the app to be sure that nothing will mess up the state (unless we’re skipping actions or making any changes in our reducers):