Chapter 3. Debugging Redux applications

Debugging isn’t only a thing you do when you’re given a bug report. The same tools and developer experience are essential to developing new features, too. In chapter 1, you learned that Redux was born out of a desire for a better client-side development experience. In this chapter, we’ll talk about a few areas where the Redux developer tools can provide better insight into an application, save valuable developer hours, and make for a more enjoyable day on the job.

Historically, time spent tracking down unexpected behavior could be one of the most egregious time sinks in a developer’s day. Chasing state changes in a complex application using two-way databinding has sunk many developer days—we should know. However, the Flux architecture pattern successfully reduces part of the mental overhead required to keep up with state changes, thanks to its unidirectional dataflow. Standardizing on actions as the vehicles of state change introduced a certain clarity: regardless of what initiated it, a change in state can be traced back to an action.

3.1. Introducing the Redux DevTools

3.2. Time-travel debugging

3.3. Visualizing changes with DevTools monitors

3.4. Implementing the Redux DevTools

3.5. The role of Webpack

3.6. Hot module replacement

3.7. Preserving local state with React Hot Loader

3.8. Exercise

3.9. Solution

Summary