atomWithDefault: setting RESET twice only calls getDefault once

[martinhath]

First off, I'm not sure if this is a bug or an intended part of the atom, so I was hesitant to mark it as a bug.

If you have an atomWithDefault you can set it to RESET to have it initialize again. I use this to initialize an atom with a fetch to a backend service that we might want to update locally (either for optimistic updates, or for other reasons). Sometimes I want to ensure that the fetch is called again.

atomWithDefault almost works here, but not quite. If you set the atom to RESET when the internal state is EMPTY, nothing happens, because the internal state is not changed. (here is the implementation) I can see that for other use-cases this is valuable, for instance if the initializer is pure (so it doesn't matter) or expensive to run (as an optimization).

Here's a codesandbox to show off a possible implementation. The first set of buttons are for atomWithDefault, and the second is with my custom behavior. Clicking "re-fetch" RESETs the state and sets it to a random value. Successive clicks to the first button does nothing, but to the second it does update every time.

I'm happy to have the custom version in my codebase, but thought I'd post this here in case this really is a bug, or if changing the behavior is better. Or, if this is something that should be documented in the docs for atomWithDefault.

[dai-shi]

RESET isn't "re-fetch" or "re-evaluate", and I think the current behavior and the implementation is by design.

It should be refresh counter, like atomWithRefresh. (Otherwise, setting RESET twice in sync will be NO-OP.)

I think the discussion #1914 is somewhat related, but not similar.

[martinhath]

Yeah, the behavior of Refresh is more what I need for my use-case. I was mostly curious whether the current implementation was by-design or not.

RESET isn't "re-fetch" or "re-evaluate",

It does re-evaluate sometimes though, as my codesandbox demonstrates. I got thrown off by this when debugging, because it was clear from the code that resetting the atom didn't reset the atom value to the result of the initial call of the initializer, but it called the initializer again (sometimes, namely when the atom has been set). It was confusing that the initializer was called depending on internal state of the atom.

I think it would be clearer if either the initializer is always called, or always just called once (and that this is the resulting value when resetting the atom). These behaviors are different, but both are intuitive and I can imagine use-cases for both. I'm not sure I can come up with a use-case where the existing behavior is exactly what I want.

[dai-shi]

This is by design.

set(something); // override
set(RESET); // triggers re-evaluate
set(RESET); // shouldn't re-evaluate, should be NO-OP