store.set(...) vs. useSetAtom(...)?

[elliotwaite]

If I'm only using a single store and I have access to it through store = unstable_createStore(), what are the differences between using:

store.set(anAtom, newValue)

and:

const setAtom = useSetAtom(anAtom)
...
setAtom(newValue)

From looking at the code, it looks like store.set(...) may not support using versioned write. Is that true?

Are there other differences?

Initially I was wondering if there were any gotchas I have to look out for when using store.set(...), but then I also started wondering what would happen if I replaced all the parts of my code that use the useSetAtom(...) ... setAtom(...) pattern to instead just use store.set(...).

[dai-shi]

If you are using just one external store with unstable_createStore, store.set(...) is the same as setAtom(...). I don't think there are technical gotchas, but you may not want to mix them (metal model gotchas, so to say).
In the future, there might be some features that would only be allowed with an internal store. (Like, experimental versioned write, which you shouldn't use as of now.)

[elliotwaite]

Okay, got it. Thanks!

[AbdouMoumen]

@dai-shi as a follow up to this question, is the guidance still that it's OK to use both approaches interchangeably? In my scenario, I'm abstracting the state management and was using hooks for both getting and setting the data. I'm now wondering if it's OK to use regular functions for the setters, while keeping the custom hooks for the getters.

const store = getDefaultStore();

const myDataAtom = atom<MyData>();

const useMyData = useAtomValue(myAtom);
const setMyData = (data: MyData) => store.set(myAtom, data);

[dai-shi]

As long as you use only one (default) store, you can use it interchangeably, technically speaking. You can confirm how useSetAtom is implemented.

But, in general, we prefer useSetAtom if possible, because it's cleaner atom model without relying on the Store API.