Doesn't seem to work with a custom store?

[tec27]

I've tried various combinations to make this work with jotai's Provider, but nothing seems to work.

I've tried:

function App() {
  return (
    <Provider store={store}>
      <DevTools store={store} />
    <Provider>
  )
}

function App() {
  return (
    <Provider store={store}>
      <Dev />
    <Provider>
  )
}

function Dev() {
  const store = useStore()
  return <DevTools store={store} />
}

function App() {
  return (
    <Provider store={store}>
      <DevTools />
    <Provider>
  )
}

In all cases, the DevTools never sees any atoms. I always see "No Atoms found!". If I remove the Provider, they all show up (but this is unworkable for my application).

It doesn't look like there is a test for the Provider case, only the non-Provider one, so maybe this functionality is just broken currently?

[arjunvegda]

Thanks for reporting!

Do you have multiple versions of Jotai yarn why jotai? It's probably because we're declaring jotai as a dependency here 🤔.

Could you try this build in your project and see if it fixes it? Here is the link - https://ci.codesandbox.io/status/jotaijs/jotai-devtools/pr/190/builds/620643 (See Local Install Instruction)

[tec27]

Seems to be all the same jotai version:

$ pnpm why jotai
Legend: production dependency, optional only, dev only

devDependencies:
jotai 2.12.4
jotai-devtools 0.12.0
└── jotai 2.12.4

Still doesn't work with that new version either (and I would expect that if this were the issue, it also wouldn't start working just by removing the Provider?)

[arjunvegda]

Thanks for taking a look! It does not seem to be a case of dual module hazard 🤔.

I'm not able to reproduce it using the latest versions (here is a working stackblitz with your examples).

Do you want to fork it and create a repro?

[tec27]

I've tried and been unable to repro on stackblitz. I thought it might be weirdness with react-compiler or StrictMode but neither of those seem to cause issues there.

Weirder still, I've seen it work in my own app now, although once I restarted my webpack server it was no longer working, even though none of the code had changed. I'll dig a bit more and try to figure out what's going on.

[tec27]

Ah I see the issue, I didn't realize this library was overriding createStore to enable functionality. Since you're doing that override via a top-level call, if I call createStore at the top-level then the behavior is import-order-dependent.

I changed my createStore call to be lazy, but this still ended up being a problem because the jotai-devtools import didn't happen until React rendered my app, and I had other code running that needed the store (and thus created it). My current fix is to dynamically import jotai-devtools at the top-level outside of production, and await that promise before I do any other initialization of my app.

It might be nice if we could create the composed devtools store ourselves (or control the timing of it), maybe similarly to how redux-devtools works. For the time being you might want to document this behavior. It's particularly painful given that the advice is to only import the devtools in development mode, so conditional/lazy imports are probably common.

[arjunvegda]

Thanks for the deep dive. We're soon going to open up the gates for usage in production, too. I'm still having a hard time reproducing this with my current structure. Could you create a small repro? I'm curious to see how your app is set up. 🤔

[tec27]

Sure, here's a minimal repro: https://stackblitz.com/edit/vitejs-vite-gychvq98?file=src%2FApp.tsx

[tec27]

Also a bit more about why this is kind of a pain to work around:

1. You have completely separate code for CJS and ESM. This isn't completely uncommon but can be kind of problematic. If I try to use a conditional synchronous require in webpack, e.g.

if (NODE_ENV !== 'production') {
  require('jotai-devtools')
}

then webpack will give me the CJS version. If I later import the devtools to render them, e.g.

import { DevTools } from 'jotai-devtools'

function App() {
  return <DevTools />
}

then I will get the ESM version. The CJS version has all of its own infrastructure, components, functions, variables, etc., so even though it has wrapped my store, that wrapping does not work with the ESM component; the ESM component will not see my atoms.

2. I'm not completely sure why, but webpack will strip a bare import of this module (e.g. import 'jotai-devtools'), I guess it assumes there are no side effects? This means that if I use my webpack configuration to ignore the jotai-devtools import in production, things still confusingly do not work and my store remains unwrapped. I have to import something from the module to get webpack to keep the import for me. Since I have a linter/formatter that removes unused imports, I also have to do something special to make sure that import doesn't get deleted.

[tec27]

Ah I see the reason for 2: your package.json has a sideEffects field that lists only the CSS file(s):

jotai-devtools/package.json

Lines 9 to 11 in 54889d3

	"sideEffects": [
	"*.css"
	],

This should probably be corrected since your JS has side effects too

[arjunvegda]

This is super helpful - thank you! And you’re absolutely right: we should definitely add the JS files to sideEffects. That was missed in the last release when we switched over to Jotai’s new store extension approach.

Would you be interested in creating a PR to address this? ^

As for the CJS/ESM situation, I’m fully aware of the issues. My plan is to eventually do a complete overhaul of the library - drop CJS support entirely, probably remove Mantine, and add some new features. I just haven’t had the time to rearchitect everything yet. If you’re open to it, I’d be happy to collaborate with you on this!

[nathanhleung]

Ah I see the issue, I didn't realize this library was overriding createStore to enable functionality. Since you're doing that override via a top-level call, if I call createStore at the top-level then the behavior is import-order-dependent. [...] I changed my createStore call to be lazy

I was running into this issue too (was using a custom store and no atoms were showing in the devtools) and changing my createStore call to be lazy also resolved my issue. Thanks @tec27!

+ import { memoize } from "lodash-es";

- export const store = createStore();
+ export const getStore = memoize(createStore);

It might be nice if we could create the composed devtools store ourselves (or control the timing of it), maybe similarly to how redux-devtools works.

@arjunvegda What do you think about exporting composeWithDevTools from the jotai-devtools/utils entrypoint as well and advising folks with custom stores to manually compose in the docs/README? Seems like composeWithDevTools should be a no-op if createStore is already patched, so no harm if jotai-devtools is already being imported first — but this would also prevent the issue that me and @tec27 are running into.

jotai-devtools/src/utils/internals/compose-with-devtools.ts

Lines 231 to 244 in 5a44e7f

	export const composeWithDevTools = (
	store: Store,
	): typeof store | WithDevToolsStore<typeof store> => {
	// Check if the store is already composed with DevTools
	if (isDevToolsStore(store)) {
	return store;
	}
	if (isDevStore(store)) {
	return __composeWithDevTools(store);
	}
	return store;
	};

Then @tec27 could do something like this:

import { memoize } from "lodash-es";

- export const getStore = memoize(createStore);
+ export const getStore = memoize(() => {
+  const store = createStore();
+  if (process.env.NODE_ENV === "development") {
+    return composeWithDevTools(store);
+  }
+  return store;
+ });
});

Happy to help out with a PR if this direction sounds promising.