Skip to content

Compose createDevStore with previous createStore#199

Open
dmaskasky wants to merge 2 commits into
jotaijs:mainfrom
dmaskasky:dmaskasky-compose-with-prevstore
Open

Compose createDevStore with previous createStore#199
dmaskasky wants to merge 2 commits into
jotaijs:mainfrom
dmaskasky:dmaskasky-compose-with-prevstore

Conversation

@dmaskasky
Copy link
Copy Markdown
Member

Summary

If a previous createStore has already overridden createStore, we should try our best to compose with it.

@codesandbox-ci
Copy link
Copy Markdown

codesandbox-ci Bot commented Jul 22, 2025

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.

Comment on lines +165 to +180
const prevStore = prevCreateStore?.();
const buildingBlocks = (
prevStore ? INTERNAL_getBuildingBlocksRev1(prevStore) : []
) as BuildingBlocks;
buildingBlocks[0] ??= new WeakMap();
buildingBlocks[1] ??= new WeakMap();
buildingBlocks[6] ??= {};
const storeHooks = INTERNAL_initializeStoreHooks(buildingBlocks[6]);
const atomWrite = buildingBlocks[8];
buildingBlocks[8] = (atom, get, set, ...args) => {
if (inRestoreAtom) {
return set(atom, ...args);
}
return atomWrite
? atomWrite(atom, get, set, ...args)
: atom.write(get, set, ...args);
};
const store = INTERNAL_buildStore(...buildingBlocks);
const [atomStateMap, mountedAtoms] = buildingBlocks;
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dai-shi
I think we need more thought around how to derive a store from a previous store. Currently, overriding certain building blocks won't work as expected.

Copy link
Copy Markdown
Member

@dai-shi dai-shi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, thanks for working on this.

Comment thread src/utils/internals/compose-with-devtools.ts Outdated
Comment thread src/utils/internals/compose-with-devtools.ts Outdated
@dmaskasky dmaskasky force-pushed the dmaskasky-compose-with-prevstore branch 2 times, most recently from 26b1d10 to 5c27901 Compare July 23, 2025 08:23
@dmaskasky dmaskasky force-pushed the dmaskasky-compose-with-prevstore branch from 5c27901 to 2c586d0 Compare July 23, 2025 09:07
@dmaskasky dmaskasky requested a review from dai-shi July 23, 2025 09:10
const prevStore = prevCreateStore?.() ?? INTERNAL_buildStore();
const buildingBlocks = [
...INTERNAL_getBuildingBlocksRev1(prevStore),
] as BuildingBlocks;
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't it already mutable without the type annotation?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think buildingBlocks should be frozen.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it should be frozen. I'm only talking about the typing. Doesn't this work?

  const buildingBlocks = [
    ...INTERNAL_getBuildingBlocksRev1(prevStore),
  ];

@sebinsua
Copy link
Copy Markdown

Since updating jotai-devtools and jotai in my project, the devtools shows no atoms at all.

Do you know if this fixes that issue? It might somehow relate to my project using a custom store or it could be something else. I've not been able to work out what's happening yet.

@planttheidea
Copy link
Copy Markdown

@dmaskasky is this PR still active? I think @sebinsua is facing the same issue that is mentioned in #212 (which, admittedly, I am facing myself), and I believe this could resolve the issue there since it is due to the race condition of calling createStore.

@dai-shi
Copy link
Copy Markdown
Member

dai-shi commented Feb 4, 2026

This reminds me:

@dmaskasky
We'd like to drop INTERNAL_overrideCreateStore if possible.
Could we use store mutation approach like pmndrs/jotai#3226 (reply in thread) ?

import { createStore } from 'jotai';
import { attachDevStoreMethod }  from 'jotai-devtools';

const store = createStore();
attachDevStoreMethod(store); // this is a new usage [BREAKING CHANGE]

For the default store, we could mutate it in the library.

// in jotai-devtools code
const defaultStore = getDefaultStore();
attachDevStoreMethod(store);

cc @arjunvegda

@dmaskasky
Copy link
Copy Markdown
Member Author

Would this mean jotai would depend on jotai-devtools?

@dai-shi
Copy link
Copy Markdown
Member

dai-shi commented Feb 4, 2026

Would this mean jotai would depend on jotai-devtools?

No.

For the createStore case, users has to attach it. For the default store case, it's a side effect of importing jotai-devtools.

@dai-shi
Copy link
Copy Markdown
Member

dai-shi commented Feb 4, 2026

Oh, it won't work with <Provider> use case. My oversight.
I think we need to relay on store hooks, rather than store mutation.

@dmaskasky
Copy link
Copy Markdown
Member Author

I wonder if ecosystem libraries would use createStore directly.

@dmaskasky
Copy link
Copy Markdown
Member Author

It would be nice if the override would have some way to remove the override.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants