feat(vanilla): new store listeners for devtools

[dai-shi]

This supersedes #1965.

Two improvements:

• It doesn't notify on restore.
• It comes with flushed set.

Also, we added the notion of "revision" which means we will probably keep improving/changing in the future.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
jotai	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jun 8, 2023 1:50am

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit f57a26b:

Sandbox	Source
React	Configuration
React Typescript	Configuration
React Browserify	Configuration
React Snowpack	Configuration
Next.js	Configuration
Next.js with custom Babel config	Configuration
React with custom Babel config	Configuration

[github-actions]

Size Change: +619 B (+1%)

Total Size: 66.9 kB

Filename	Size	Change
dist/system/vanilla.development.js	3.76 kB	+203 B (+6%)	🔍
dist/umd/vanilla.development.js	4.55 kB	+210 B (+5%)	🔍
dist/vanilla.js	4.46 kB	+206 B (+5%)	🔍

ℹ️ View Unchanged

Filename	Size
dist/babel/plugin-debug-label.js	916 B
dist/babel/plugin-react-refresh.js	1.15 kB
dist/babel/preset.js	1.39 kB
dist/index.js	229 B
dist/react.js	1.05 kB
dist/react/utils.js	1.23 kB
dist/system/babel/plugin-debug-label.development.js	1.09 kB
dist/system/babel/plugin-debug-label.production.js	764 B
dist/system/babel/plugin-react-refresh.development.js	1.29 kB
dist/system/babel/plugin-react-refresh.production.js	935 B
dist/system/babel/preset.development.js	1.57 kB
dist/system/babel/preset.production.js	1.14 kB
dist/system/index.development.js	236 B
dist/system/index.production.js	167 B
dist/system/react.development.js	1.17 kB
dist/system/react.production.js	701 B
dist/system/react/utils.development.js	677 B
dist/system/react/utils.production.js	424 B
dist/system/utils.development.js	241 B
dist/system/utils.production.js	175 B
dist/system/vanilla.production.js	1.91 kB
dist/system/vanilla/utils.development.js	4.46 kB
dist/system/vanilla/utils.production.js	2.72 kB
dist/umd/babel/plugin-debug-label.development.js	1.07 kB
dist/umd/babel/plugin-debug-label.production.js	850 B
dist/umd/babel/plugin-react-refresh.development.js	1.29 kB
dist/umd/babel/plugin-react-refresh.production.js	1.02 kB
dist/umd/babel/preset.development.js	1.53 kB
dist/umd/babel/preset.production.js	1.25 kB
dist/umd/index.development.js	371 B
dist/umd/index.production.js	321 B
dist/umd/react.development.js	1.18 kB
dist/umd/react.production.js	785 B
dist/umd/react/utils.development.js	1.4 kB
dist/umd/react/utils.production.js	1.01 kB
dist/umd/utils.development.js	386 B
dist/umd/utils.production.js	334 B
dist/umd/vanilla.production.js	2.11 kB
dist/umd/vanilla/utils.development.js	5.18 kB
dist/umd/vanilla/utils.production.js	3.18 kB
dist/utils.js	236 B
dist/vanilla/utils.js	5.05 kB

_{compressed-size-action}

[dai-shi]

@arjunvegda check out the new one!

[arjunvegda]

This is great! The write and restore functionality is working as expected.

Is there a way to trigger write-async when a promise is resolved? Reference PR #1920

[dai-shi]

Is there a way to trigger write-async when a promise is resolved? Reference PR #1920

Our change here is about store listeners. Promise resolution isn't in it. (Our mental model is, Jotai store doesn't care about promise values.)
Basically, I still think you can handle promise resolution on your end.
We could add some kind of "promise listeners", but it just offload the task from jotai-devtools to jotai. (I mean, I don't think it adds any new capability. I might be missing something though. Maybe, if we want to track continuePromise. 🤔 )

[arjunvegda]

Our mental model is, Jotai store doesn't care about promise values.

I get your perspective now! I considered promise values as a first-class citizen for Jotai, similar to any other non-promise value. So to me, it's natural to fire an event (state change for example) when the async value in the store gets updated, similar to how we do it for any other non-promise value. 😅

jotai-devtools sounds like a better place for it then! 🙌

[arjunvegda]

LGTM!

[dai-shi]

Yeah, only the exception is that it wraps a promise to match with react behavior, like continuePromise, resolvePromise, abortPromise and so on. Now I think, ideally, this should go into jotai/react which would simplify jotai itself. We may try that road in the future, when we know more about react use best practice which doesn't exist yet.

[dai-shi]

@arjunvegda Can you try if/how flushed set helps in devtools?

[arjunvegda]

@arjunvegda Can you try if/how flushed set helps in devtools?

This new API and access to flushed is a great addition. I played around with this API in devtools this weekend. I don't plan to use it immediately, perhaps after Time Travel is released. But here are some ideas

• Create atom based subscription model for time travel to update the diff map instead of re-creating one every time there is a change
• Construct a map of atoms using these "atom level" subscriptions on the atom viewer tab and allow users to see diffs by atom
• Maybe use this API to build a stack trace whenever there is a write event

---

This might be a stretch, but it'd be even nicer [in the future] to pre-hook for writing as well, maybe pre-write or before-write. We could use those events to save stack traces on dev tools before the write occurs.

[dai-shi]

tbh, I thought about pre-write but I'm not a big fan of it.
I would like to offload as much as possible to jotai-devtools and make jotai as slim as possible.

So, an ideal way would wrap store.

const store = devtools(createStore());

const App = () => {
  return (
    <Provider store={store}>
      <DevTools store={store} />
      {/* your app */}
    </Provider>
  );
};

// OR

const store = createStore();

const App = () => {
  return (
    <ProviderWithDevTools store={store}>
      {/* your app */}
    </ProviderWithDevTools>
  );
};

This doesn't work with the default store, so we would need a hook for it. 🤔 (Yeah, setDefaultStore may make sense.)

I wonder if we can eliminate mountedAtom in store.

[arjunvegda]

Thank you!!