Chapter 3. Debugging Redux applications
This chapter covers
- Working with the Redux developer tools
- Understanding the role of monitors
- Using hot module replacement
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.