Save 37% on Redux in Action. Just enter code fccgarreau into the discount code box at checkout at manning.com.

Debugging isn’t only a thing you do when you’re given a bug report. When it comes to mobile applications this bug tracking software could be a useful tool to developers. The same tools and developer experience are essential to develop new features, too. Redux was born out of a desire for a better client-side development experience.

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. The Flux architecture pattern successfully reduces some 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.

The list of actions dispatched in an application forms what can be thought of as a transaction log. When viewed sequentially, they can tell the story of a user’s interaction with the application fairly comprehensively. Wouldn’t it be nice to visualize those actions in real time? To see them as they’re dispatched and the data they contain?

Introducing the Redux DevTools

The Redux developer tools, or DevTools for short, augment your development environment for real-time visualization of actions. Let’s take a look at what the developer tools might look like in the context of Parsnip, a task management application.

Figure 1 The Redux DevTools can be used to display actions in real time.

In the right page (figure 1), you can see a highlighted list of items — the actions which have been dispatched to produce the state displayed. Given this list of actions, you can tell exactly what we’ve been up to within Parsnip without having to observe us do it: the app was initialized, a third task was created, and then the second task was edited. You can see why it might be handy to have immediate feedback on each new action as they’re dispatched. For every action, you can be sure that the payload looks the way you intended. Still, there’s much more that you can do with the DevTools.

You’ll notice that below each action in the right page is a snapshot of the Redux store. Not only can we view the action produced, we can see the application state that resulted from that action. Better still, we can dig into the Redux store and see, highlighted, the exact values that changed as a result of the action.

Figure 2 The DevTools highlight attributes of the Redux store which have changed as a result of the action.

Time-travel debugging

But wait, there’s more! Clicking the title of an action in the DevTools toggles that action off. The application state is recalculated as if that action was never dispatched, even if the action’s in the middle of long list of actions. Click it again, and the application returns to its original state.

Figure 3 Toggling an action recalculates the application state as if the action was never dispatched.

The rewinding and replaying of actions like this is what inspired the name time-travel debugging. To determine what Parsnip would look like if we hadn’t created a third task, there’s no need to refresh and re-create the state — hop back in time by disabling that action.

One extension for the DevTools even provides a slider UI to scroll back and forward through actions, seeing their immediate effect on the application. Note that no extra configuration or dependency is required to use time-travel debugging; it’s a feature of the DevTools. More specifically, it’s a feature of many DevTool monitors.

Visualizing changes with DevTools monitors

The Redux DevTools provide an interface to the actions and Redux store but don’t provide a way to visualize that data. That work is left for monitors. This is a conscious decision to separate the two concerns, enabling the community to plug and play their own visualizations of the data to best fit their needs. Figure 4 illustrates this idea conceptually; one or more monitors can be configured to display the data provided by the DevTools.

Figure 4 Various monitors can be combined with the Redux DevTools to visualize actions and store data.

Several of these monitors, including those listed in Figure 4, are open source libraries and ready for use. In the screenshots from the previous sections, you’ve been viewing the so-called default monitor, the Log Monitor. Other monitors worth mentioning are the Slider Monitor, described in the previous section, and the Inspector Monitor, the default monitor of the Redux DevTools Chrome extension. Inspector provides a user interface similar to the Log Monitor, but allows for easier filtering of actions and store data.

Note Several more monitors can be found in the README of the Redux DevTools repository on GitHub (https://github.com/gaearon/redux-devtools). Again, the DevTools feed the data to any monitor; if you can’t find a monitor feature you’re looking for, that may be your cue to build your own. The open source community will thank you for your contribution!

Implementing the Redux DevTools

Let’s say that you’ve been tasked with implementing the DevTools in the budding new application, Parsnip. The first choice you must make is how you’d like to view the monitors. Here are a few popular options:

• In a component within the application

• In a separate popup window

• Inside your browser’s developer tools

For a few reasons, our personal preference is the last option — to use the Redux DevTools via the Chrome browser developer tools. First, the installation is easier than any other option. Second, the integration with our existing development workflow is seamless. Finally, the extension includes a robust set of monitors that continues to meet our needs out of the box.

As JavaScript developers, many of us already spend a lot of time within the Chrome DevTools — inspecting elements, using breakpoints, flipping between panels to check the performance of requests, and so on. Installing the Redux DevTools Chrome plugin adds one more panel, and clicking it reveals the Inspector and other monitors. We don’t miss a beat.

Note Redux and Chrome both refer to their developer tools by the abbreviation “DevTools.” References to the Redux DevTools within the Chrome DevTools can get confusing; pay extra attention to the difference. Going forward, we’ll specify which we’re referring to.

Two steps are required in this process: installing the Chrome browser extension and hooking the Redux DevTools into the store. Installing the Chrome extension is the simpler of the two. Visit the Chrome Web Store, search for Redux DevTools, and install the first package by the author remotedev.io.

Onto the second step, adding the Redux DevTools to the store. Although this configuration can be done without another dependency, the redux-devtools-extension package is a friendly abstraction that reads like English. We’ll download and instrument the package now. Install and save the package to your development dependencies with the following command:

  
 npm install –D redux-devtools-extension
  

Once installed, we’ll import and pass a function called devToolsEnhancer to the store. As a refresher, Redux’s createStore function takes up to three arguments: a reducer, an initial state, and an enhancer. In the case that only two arguments are passed, it’s presumed the second argument is an enhancer and there’s no initial state. Listing 1 is an example of this case. Enhancers are a way to augment the Redux store and the devToolsEnhancer function is doing that: connecting the store with the Chrome extension to provide additional debugging features.

  
 import { devToolsEnhancer } from 'redux-devtools-extension';
 …
 const store = createStore(tasks, devToolsEnhancer());
 …
  

After you’ve completed adding the Redux DevTools enhancer to the createStore method, you can begin to use the tools. Flip back to the app in the browser and open the Chrome developer tools. If you’re in unfamiliar territory, from the Chrome navigation bar, select View, then Developer, and finally Developer Tools. The Chrome DevTools opens in a separate pane in your browser, typically with the Elements panel displayed by default. From the navigation bar within the Chrome developer tools, the Redux DevTools can be found by selecting the new Redux panel, made available by the Redux DevTools Chrome extension.

Figure 5 Navigate to the Redux DevTools via the Redux panel in the Chrome developer tools.

Once you’ve navigated to the Redux DevTools, you should see the Inspector Monitor by default, which you can confirm by verifying that the upper left menu of the tools reads Inspector.

When an action is selected, the other half of the Inspector Monitor displays data about the action or the Redux store, depending on the filter you’ve selected. The Diff filter is particularly helpful for visualizing the impact that an action had on the store. The menu in the upper left changes the display between the Inspector, Log, and Chart monitors. A button is near the bottom on the panel, with a stopwatch icon that opens a fourth monitor: the Slider Monitor. Pause here to take some time to explore these tools pointed out in figure 6, because they make for a delightful developer experience and will save your backside more times than you’ll be able to count.

Figure 6 The skip, diff filter, and monitor menu options offer unique ways to visualize and debug state effects.

If you think you’d prefer to use the Redux DevTools in a component within your app, the setup process is slightly more long-winded. You’ll likely make use of the Dock Monitor—a component that can be shown or hidden in your application and that displays the Log Monitor, or another monitor, within it. Full instructions can be found in the README of the Redux DevTools repository on GitHub at https://github.com/gaearon/redux-devtools.

If you want to learn more about the book, check it out on liveBook here and see this slide deck.