parameterized atom selectors

[joprice]

I have many atom selectors like the following:

const useAtEnd = (id: Id) =>
  useAtomSelector(({ get }) => {
    const { timestamp, duration } = get(playerOffsetAtom, [id]);
    const atEnd = timestamp != null && duration != null && timestamp >= duration;
    return atEnd;
  });

I noticed that react was not getting updates, even though the selector was running correctly on each change to the player offsets atom. I realized that I didn't parameterize the selector, so I rewrote it to

const useAtEndSelector = ({get}: AtomGetters, id: Id) => {
    const {timestamp, duration} = get(playerOffsetAtom, [id]);
    const atEnd = timestamp != null && duration != null && timestamp >= duration;
    return atEnd;
  };

  const useAtEnd = (id: Id) => useAtomSelector(useAtEndSelector, id);

After that, things worked perfectly. The solution makes sense to me, but I'm not sure I understand why. I would have expected in the original version to work, but not be correct in the sense that the results are being collapsed, as the id is not being taken into account. Maybe it's the inline selector that was the issue, but I saw many tests with inline selectors (and I have a few of them in my codebase, but perhaps they have similar issues). Should the selector provided to useAtomSelector always be a stable reference?

[bowheart]

Hey @joprice inline selectors are a beast 'cause of how React makes us do things for concurrent/strict mode. Can you fill me in on a few details:

• Zedux version
• React version
• Whether you're using StrictMode
• Whether the component that calls useAtEnd is ever suspended

Your first example is supposed to work. That said, it is a best practice to make selectors stable references wherever possible due to:

• (small) performance overhead. Since inline selectors can close over anything (like your id), Zedux has to run it on every rerender and do some clever stuff to swap out the function reference.
• the fact that stable selectors are named functions by default, making them much easier to find in the ecosystem's selector cache.
• (not supposed to be a reason, but it has been in several Zedux releases and possibly still is, despite our tests:) the potential to encounter some bugged edge case with inline selectors, especially with concurrent/strict mode

We actually don't use useAtomSelector directly with inline selectors. We created a useAtomSelectorMemo hook we use internally that uses useMemo to make the inline selector reference stable.

export function useAtomSelectorMemo<T>(
  selector: SelectorTemplate<T, []>, // `AtomSelectorOrConfig` in v1
  deps: DependencyList = []
) {
  return useAtomSelector(useMemo(() => selector, deps));
}

[joprice]

• zedux - 1.3.4
• react - 19.1.0
• no strict mode
• the atom does have a promise, but i'm not using useSuspendingSelector with it at the moment

I just hit this issue again today and switched all my code over to your memo version, and it's working great. It would be nice if inline functions worked out of the box and it was only a performance degradation (same as in react), since this is a correctness issue: selector runs but the component renders with stale state. But, I'm happy with the two workarounds of either using a stable function or making use of react memoization.

[bowheart]

Thanks @joprice. I spent a while on this and made AI spend a while on this and it was useless. But I eventually found one edge case that can lead to stale values. I patched it in #294, and published the fix in v1.3.5.

I don't know if this fully resolves this issue, but it seems likely to me right now. Let me know if v1.3.5 helps.