Filter redux devtools state in useAtomsDevtools

[axel-havukangas-tt]

Using useAtomsDevtools with Redux DevTools is a really powerful combination that makes it easy and unintrusive to inspect the application state. The only issue I've been having is the amount of noise in the state browser caused by various internal atoms for example within the loadable utility. Filtering out private atoms was hinted at in pmndrs/jotai#931 (comment), but not available at the moment.

One possible partial solution would be to expose the stateSanitize configuration value when creating the redux devtool connection. Then developers could use that to filter out unwanted atoms from the state. Unfortunately the debugPrivate value of atoms isn't available in that context, so one is limited to the debugLabel. My solution has been to use a hidden label for any atoms that I want to filter away in the devtools.

My current workaround for this is to wrap the window.__REDUX_DEVTOOLS_EXTENSION__.connect function with my own. Like this

  if (window.__REDUX_DEVTOOLS_EXTENSION__ && !hasReduxDevtoolsBeenWrapped) {
    const originalConnect = window.__REDUX_DEVTOOLS_EXTENSION__.connect

    const wrappedConnect = (preConfig: ReduxDevtoolsConfig): ReduxDevtoolsConnectResponse => {
      // Inject custom options to the connect function
      // https://github.com/reduxjs/redux-devtools/blob/main/extension/docs/API/Arguments.md
      return originalConnect({
        // Customize the state visible in the devtools
        // Move atom values to top level, removing dependencies
        stateSanitizer: ({ values }: JotaiDevtoolsState) =>
          Object.fromEntries(
            Object.entries(values)
              // Remove atomXX prefix from value names
              .map<[string, unknown]>(([key, value]) => [key.replace(/^atom[0-9]+:?/, ""), value])
              // Remove atoms marked as hidden
              .filter(([key]) => key !== "hidden")
              // Remove atoms without any label
              .filter(([key]) => key !== ""),
          ),
        ...preConfig,
      })
  }

  window.__REDUX_DEVTOOLS_EXTENSION__.connect = wrappedConnect
  hasReduxDevtoolsBeenWrapped = true
}

but life would of course be nicer without the extra boilerplate.

[arjunvegda]

Hi @axel-havukangas-tt

Thanks for reaching out! Yes, we don't have first-class support for debugPrivate for Redux Extension. I'm open to adding an option to the hook that helps users configure this. Would you like to contribute?

What you have is also a good workaround!

By the way, we also have UI-based DevTools that come with this feature out-of-the-box. Have you tried that? This guide should help you get started

[axel-havukangas-tt]

Yes, I'd be happy to help out with implementing this functionality. What kind of solution did you have in mind? Should we expose the stateSanitizer options from window.__REDUX_DEVTOOLS_EXTENSION__.connect to the caller of useAtomsDevtools, or should we implement the private atom filtering as part of the hook? I wouldn't be opposed to providing both options to the caller.

As for the <DevTools /> UI component. It looks nice and works well, but for our use cases the way it overlays on top of the webpage unfortunately causes some issues. So we decided to keep all development tools within the browser web inspector.

[arjunvegda]

That's fair! I was looking into Chrome's new PiP API that lets you pop the extension out into a separate window but ran into an iframe-related blocker 😅

I like your idea of implementing the filter as part of the hook. We could make it configurable via the options param and add shouldShowPrivateAtoms. <DevTools/> hides all the private atoms by default, should we also do the same to keep it consistent?

[axel-havukangas-tt]

Sounds like a plan. shouldShowPrivateAtoms under options feels like a natural fit.

Looking at the code, I decided the best place to implement the change seems to be under useAtomsSnapshot which is used by both useAtomsDevtools and DevTools. With this approach we get the same shared functionality in use in all places.

I went ahead and created a PR at #105, but unsure about the review and PR practices in the project so leaving it in draft for the moment.

[arjunvegda]

That's perfect! Thanks again for your contribution!

[arjunvegda]

Released in 0.7.0 🚀