Compose createDevStore with previous createStore#199
Conversation
|
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. |
| 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; |
There was a problem hiding this comment.
@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.
dai-shi
left a comment
There was a problem hiding this comment.
Again, thanks for working on this.
26b1d10 to
5c27901
Compare
5c27901 to
2c586d0
Compare
| const prevStore = prevCreateStore?.() ?? INTERNAL_buildStore(); | ||
| const buildingBlocks = [ | ||
| ...INTERNAL_getBuildingBlocksRev1(prevStore), | ||
| ] as BuildingBlocks; |
There was a problem hiding this comment.
Isn't it already mutable without the type annotation?
There was a problem hiding this comment.
I think buildingBlocks should be frozen.
There was a problem hiding this comment.
Yes, it should be frozen. I'm only talking about the typing. Doesn't this work?
const buildingBlocks = [
...INTERNAL_getBuildingBlocksRev1(prevStore),
];|
Since updating 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. |
|
@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 |
|
This reminds me: @dmaskasky 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 |
|
Would this mean jotai would depend on jotai-devtools? |
No. For the |
|
Oh, it won't work with |
|
I wonder if ecosystem libraries would use createStore directly. |
|
It would be nice if the override would have some way to remove the override. |
Summary
If a previous createStore has already overridden createStore, we should try our best to compose with it.