Is using get and getInstance inside exports without register graph dependencies when evaluating atom considered safe?

[devnomic]

Is using get and getInstance inside exports function without register graph dependencies when evaluating atom considered safe? Any downside for this?

const otherAtom = atom("other", (x: string, y: string) => {
  const store = injectStore(`other-${x}${y}`);
  return store;
});
const anotherAtom = atom("another", (z: string) => {
  return api().setExports({
    doSomething: function () {
      console.log(z);
    }
  });
});

const formAtom = atom("form", () => {
  const store = injectStore({
    name: ""
  });
  const { get, getInstance } = injectAtomGetters();

  // Is using get and getInstance inside exports
  // without register graph dependencies when eval atom considered safe?
  return api(store).setExports({
    //  forward function params to another atom
    validate: function (x: string, y: string, z: string) {
      const other = get(otherAtom, [x, y]);
      const anotherInstance = getInstance(anotherAtom, [z]);

      anotherInstance.exports.doSomething();
      console.log(other);
      const { name } = store.getState();
      return other === name;
    }
  });
});

https://codesandbox.io/s/silly-wave-gpw3lh?file=/src/App.tsx

Or need to do this? (which i don't want because when using useAtomValue i need to pass all the params even tough i don't use validate function)

// Forward atom params to another atom when eval to register deps
const formAtom = atom("form", (x: string, y: string, z: string) => {
  const store = injectStore({
    name: ""
  });
  const { get, getInstance } = injectAtomGetters();

  const otherInstance = getInstance(otherAtom, [x, y]);
  const anotherInstance = getInstance(anotherAtom, [z]);
  get(otherInstance);

  return api(store).setExports({
    validate: function () {
      const other = get(otherInstance);
      const { doSomething } = getInstance(anotherInstance).exports;

      doSomething();
      console.log(other);
      const { name } = store.getState();
      return other === name;
    }
  });
});

https://codesandbox.io/s/epic-johnson-zgc172?file=/src/App.tsx:419-1029

[bowheart]

It is considered safe with one caveat - if the getInstance call creates the atom instance, it is instantiated with a ref count of 0, meaning Zedux can't clean it up automatically. Cleanup only happens when ref count goes from 1 to 0 - it can't happen if ref count never reaches 1 in the first place.

Since your other atoms don't have a ttl set though, cleanup won't happen anyway. If you're fine with that, then there is no problem here. Leaving atom instances around like that is kind of a "technical memory leak", but since those instances are automatically rediscovered the next time validate is called with the same params, you can think of it more like you're caching those instances.

Anyway, yes, this is fine. It's a feature of Zedux's cache management and we use it a lot.

If you do want to clean up those instances, there are a few ways to go about it.

• Call instance.destroy() when you're done with the instance

const anotherInstance = getInstance(anotherAtom, [z])

anotherInstance.exports.doSomething()
anotherInstance.destroy() // only destroys the instance of its ref count is 0

• Use manual graphing to trigger Zedux's auto-cleanup

const anotherInstance = getInstance(anotherAtom, [z])

// create a graph edge (incrementing ref count)
const cleanup = anotherInstance.addDependent({ operation: 'validate' })

anotherInstance.exports.doSomething()

cleanup() // remove the graph edge

The advantage of the 2nd approach is you can set a non-zero TTL on anotherAtom to keep its instances around in memory for some time before cleaning up - you can even use promises/observables to determine when the instance should be cleaned up.

The destruction walkthrough goes into more detail.

[devnomic]

I see! thank you for your thorough explanation and answer.

Just to confirm,
So in case otherAtom and anotherAtom with same params is already used somewhere in react component,
this wont trigger "technical memory leak" inside validate function with same params, because Zedux can also track the ref count using that react component to cleanup the atom, is this correct?

Btw is there any log tools that i can use to see the ref count? like ecosystem viewGraph?

[bowheart]

Zedux can also track the ref count using that react component to cleanup the atom, is this correct?

Yes, if an atom is used in both places with the same params, the same instance is reused. For example:

// in a component:
useAtomValue(otherAtom, ['a', 'b'])

// in `validate` export:
get(otherAtom, ['a', 'b'])

The first one to run will create the otherAtom-["a","b"] instance. The other one will then reuse the same instance.

If validate runs first, it will be a "technical memory leak" until useAtomValue runs and increments the instance's ref count to 1.

If useAtomValue runs first, it won't be a leak at all - validate and other places are free to use the instance while the component keeps it around.

But don't let the phrase "technical memory leak" scare you. This isn't a dangerous, aggressive leak. It's a caching feature that you can absolutely make use of. Think of it like state slices in Redux - you don't typically clean those up; you just leave them there in case the user goes back to the page or whatever.

Zedux's cache is easily discoverable. When an atom is reused with the same params, Zedux will find the existing instance. You can also inspect the cache yourself and trigger destruction manually with ecosystem.findAll() and instance.destroy(). None of that memory is actually unreachable like a real leak.

is there any log tools that i can use to see the ref count?

So I log ecosystem.viewGraph() and expand the object I'm looking for to see its dependents. The number of dependents is the ref count. I could add a refCount field to the output of .viewGraph(), but it isn't really necessary since it can be derived with:

Object.keys(ecosystem.viewGraph()[myNodeId].dependents).length

I'll make sure the dev tools display the ref count. Some info on that btw: We have an old Zedux StateHub React component that we basically abandoned a year ago. I think I'm not gonna try to resurrect it. I made a plan for the rewrite today and will start working on it tomorrow. I think I'm gonna try the whole #buildinpublic thing with it on Twitter.

I'm planning on making 3 packages - the core DevTools UI and a React component and Chrome extension that use it. Out of curiosity, which would you prefer using - a Chrome extension or dockable UI widget like React Query's?

[devnomic]

Thank you for your explanation, it's very clear now. Zedux such an amazing lib.
Actually i prefer chrome extension.