Derived overwritable atom, that re-derives when source changes

[Lesik]

I'm trying to create an atom that is derived from another atom. When the source atom changes, the derived atom should also update. In the meantime, the atom can also be overridden. But when the source atom changes again, the override should be lost.

You could have a source atom that is fetched from the network. That should be the source for the derived atom. But, the user can overwrite the derived atom, until the next fetch happens, in which case the network value should have priority (and the overridden value is lost).

For example, you might get weather data from the network, and if it's raining, you want to automatically turn on the windshield wipers. However, the user can also manually override the windshield wiper setting, so turn them off, for example. But the next time the weather data is fetched from the network, the wipers should turn back on automatically.

const weatherData = atomWithRefresh(() => fetch('/weather'));

const windshieldWipersOn = ((get) => {
  return get(weatherData).isRaining;
}, (get, set, update) => {
  set(windshieldWipersOn, update);
});

The problem I'm facing is that if an atom has a read function (as opposed to a hardcoded read value), it cannot be written to (atom not writable).

I tried working around that by having an internal value atom and an action atom:

const weatherData = atomWithRefresh(() => fetch('/weather'), ...);

const isRaining = ((get) => get(weatherData).isRaining);

const windshieldWipersOverride = atom(undefined);

const windshieldWipersOn = ((get) => {
  return get(windshieldWipersOverride) ?? get(isRaining);
}, (get, set, update) => {
  set(windshieldWipersOverride, update);
});

But of course now the windshieldWipersOverride won't auto-reset when isRaining changes. It seems like I am limited by the fact that I can't set from the read function, only from the write function, but the write function can only run manually (can't be automatically triggered).

Any pointers are much appreciated.

[dai-shi]

Is https://jotai.org/docs/recipes/atom-creators#atomwithrefreshanddefault related? Maybe not.

I think what you describe is not truly declarative. For such impure cases, often the escape hatch is selectoAtom.

[Lesik]

Thanks for your response! Unfortunately, atomWithRefreshAndDefault needs manual trigger to reset to default, whereas I would like to auto-reset whenever weatherData changes.

I don't quite understand why my use case is not truly declarative, and what one would do instead to implement the business logic I need yet keep it declarative. Could you perhaps elaborate?

How would selectAtom help in this case? I'm reading that it's for getting smaller pieces out of larger data, optionally based on a comparison function. It's the problem is not that isRaining is not updating, that works fine. It's that I can't reset the override automatically when deriving, only by user interaction.

PS: The utilities/select docs page is not listed in the sidebar navigation, hence why I haven't read it although I've read through the entire docs. Is that on purpose to hide a "dangerous" function from newcomers?

[dai-shi]

PS: The utilities/select docs page is not listed in the sidebar navigation, hence why I haven't read it although I've read through the entire docs. Is that on purpose to hide a "dangerous" function from newcomers?

#1559 (reply in thread)

[Lesik]

Hmm I might be on to something...might just be a brain fart

const atomWithAutoReset = (getter: any) => {
  let overwrittenValue: any = undefined;
  const counter = atom(0);
  return atom(
    (get) => {
      const originalValue = getter(get);
      get(counter); // subscribe to auto-reload
      const overwritten = overwrittenValue;
      overwrittenValue = undefined;
      return overwritten ?? originalValue;
    },
    (get, set, args) => {
        overwrittenValue = args;
        set(counter, (count) => count + 1);
    }
  );
};

(anys because prototyping, will fix it up later)

This "caches" the overwritten value in a regular JS variable, because that can be read from and written to from anywhere. Then it increments the counter to let re-run the read function so that any subscribers of this atom know the value changed. Since the overwritten value is set, it returns that, but also clears the overwritten value, so that next time the read function runs, it takes the value from the parent instead of the overwritten one.

@dai-shi does my code make sense? Is it a good idea? 😄

Edit: Had a wrong value assignment in the code

[dai-shi]

No, having the let variable outside atom isn't pure. The read function should be pure by design. overwrittenValue = undefined; violates it.

Theoretically, the read function could be called at any time and for multiple times.

[Lesik]

Yes I can see it now. The read function will be run whenever the source atom (getter) changes, or when the counter changes. Inside the read function, it's impossible to know which of the two triggered the change, hence it's impossible to know which one to pick.

As you said in another comment: "If you add timestamps and pick newer one, then it will be declarative." Then it would be possible to know which one to pick. But like this, it's impossible to pick.

Haha my brain hurts now and I have no idea how to implement my business logic, since clearly the business logic is not declarative. Timestamping all values doesn't sound like an elegant solution.

[dai-shi]

Hm, I think you can keep "what you are overriding".

const sourceAtom = atom('hi');
const overriddenAtom = atom(undefined);
const mergedAtom = atom(
  (get) => {
    const source = get(sourceAtom);
    const overridden = get(overriddenAtom);
    if (overridden?.source === source) {
      return overridden.override;
    }
    return source;
  },
  (get, set, update) => {
    set(overriddenAtom, { source: get(sourceAtom), override: update });
  }
);

In this case, we don't need timestamps.

[Lesik]

This is quite clever and perfectly solves my use case, thanks!

I generalized it a bit and added ts types, do you think this could be added to utils or the docs?

export const atomWithTempOverride = <
  DerivedValue,
  OverwrittenValue = DerivedValue
>(
  read: Read<DerivedValue>
) => {
  const sourceAtom = atom(read);
  const overriddenAtom = atom<{
    source: DerivedValue | undefined;
    override: OverwrittenValue | undefined;
  }>({
    source: undefined,
    override: undefined,
  });
  const mergedAtom = atom(
    (get) => {
      const source = get(sourceAtom);
      const overridden = get(overriddenAtom);
      if (overridden.source === source) {
        return overridden.override;
      }
      return source;
    },
    (get, set, update: OverwrittenValue) => {
      set(overriddenAtom, { source: get(sourceAtom), override: update });
    }
  );
  return mergedAtom;
};

[dai-shi]

Yeah, this might be a useful one in utils, but I would like to learn more use cases in a longer period. (especially, because it's close to atomWithDefault and maybe atomWithRefresh.)
For now, would you open a PR to add an atom creator recipe in docs? (we should probably split atom creators into multiple files. I will add a request in #1267.)

[dai-shi]

I'm trying to create an atom that is derived from another atom. When the source atom changes, the derived atom should also update. In the meantime, the atom can also be overridden. But when the source atom changes again, the override should be lost.

It's not declarative if you can't determine which one should be the result, the source atom or the overridden atom.
If you add timestamps and pick newer one, then it will be declarative.

[rainyEra]

I would say that it's a good recipe. I like when docs showing you problems and approach to solve it.

[WeiShengv99]

its great, l like it