Connecting Zustand to Redux DevTools

Hello! Let's dive into the next lesson.

In our previous session, we explored the concept of middleware in Zustand, understanding it as a powerful pattern for extending a store's functionality with cross-cutting concerns like logging or persistence.

Today, we'll put that theory into practice with one of the most valuable middlewares available: devtools. This lesson will guide you through integrating the devtools middleware to connect your Zustand store to the Redux DevTools browser extension. This will unlock powerful debugging capabilities, including action logging and time-travel debugging, giving you a clear view into your application's state changes.

1. Prerequisite: Installing the Redux DevTools Extension

Before we write any code, you need the right tool in your browser. The Zustand devtools middleware communicates with the Redux DevTools browser extension. If you don't have it installed, the middleware won't have anything to connect to.

Once the extension is installed, you should see its icon in your browser's toolbar.

2. Basic Integration with devtools

With the extension ready, let's connect a store. As we discussed in the last lesson, you apply middleware by wrapping your store's creator function.

First, you need to import devtools from zustand/middleware. Then, you simply pass your store's setup function as the first argument to devtools.

import { create } from 'zustand';
import { devtools } from 'zustand/middleware';

// The devtools middleware wraps your store creator function
const useBearStore = create(
  devtools(
    (set) => ({
      bears: 0,
      increase: () => set((state) => ({ bears: state.bears + 1 })),
      removeAll: () => set({ bears: 0 }),
    })
  )
);

Now, let's see what this looks like in a running application.

After this step, you can already inspect state, view action history, and even "time travel" by moving the slider in the DevTools UI to revert to previous states.

3. Configuring the DevTools for Clarity and Control

The basic integration is powerful, but in a real application, you'll want more control. The devtools function accepts an optional second argument: a configuration object.

Naming Actions

You might have noticed in the video that the actions were logged with specific names. If you don't provide a name, they will show up as "anonymous", which is not very helpful for debugging.

To fix this, you provide a name for the action as the third argument to the set function. The second argument is for controlling state replacement (which we'll cover later), so for now, you can pass undefined or false.

Here is the corrected code structure from our earlier example:

const useBearStore = create(
  devtools(
    (set) => ({
      bears: 0,
      increase: () => set(
        (state) => ({ bears: state.bears + 1 }), 
        false, // Don't replace the state
        'bears/increase' // Action name
      ),
      removeAll: () => set(
        { bears: 0 },
        false, // Don't replace the state
        'bears/removeAll' // Action name
      ),
    })
  )
);

This practice of naming actions is crucial for maintaining a clean and understandable action history in your DevTools.

Naming Stores for Multi-Store Setups

If your application grows to have multiple Zustand stores, you'll find that by default, they all try to connect to the same DevTools instance, leading to confusion. To solve this, you can provide a unique name in the devtools configuration object.

Here's how you would apply it in code:

// storeA.js
const useStoreA = create(devtools((set) => ({...}), { name: 'StoreA' }));

// storeB.js
const useStoreB = create(devtools((set) => ({...}), { name: 'StoreB' }));

Disabling DevTools in Production

You should not expose your application's internal state management in a production environment. The devtools middleware makes this easy to control with the enabled flag. By default, it's enabled in development and disabled in production, but you can override this.

Example with an environment variable check:

const useMyStore = create(
  devtools(
    (set) => ({ ... }),
    {
      name: 'MyStore',
      enabled: process.env.NODE_ENV !== 'production',
    }
  )
);

4. Middleware Order Matters

In the previous lesson, we noted that the order of middleware composition is important. When using devtools, it should generally be the outermost middleware, or at least outside of any middleware that might transform the state update itself (like immer). This ensures that devtools can accurately log the action and the resulting state change as you intend them.

This principle applies to other middleware as well. For example, when we cover persist in the next lesson, the typical order is devtools(persist(...)).

Conclusion

You have now learned how to significantly improve your debugging workflow by integrating Zustand with Redux DevTools. This is a standard practice in professional development and will save you countless hours when troubleshooting state-related issues.

Key Takeaways:

• The devtools middleware requires the Redux DevTools browser extension to be installed.
• You integrate it by wrapping your store creator: create(devtools((set) => ...)).
• For better debugging, name your actions using the third argument of the set function: set(..., false, 'action-name').
• In multi-store applications, use the { name: 'StoreName' } option to distinguish between stores in the DevTools UI.
• Use the { enabled: ... } option to disable DevTools in production environments.
• The order of middleware is important; devtools should typically be one of the outermost wrappers.

Next Lesson Preview:

Now that you can debug your store, the next logical step is to make its state persistent. In the next lesson, we will explore the persist middleware, which allows you to automatically save your store's state to localStorage and rehydrate it when the user revisits your application.