Recommended pattern for memoized state selection with parameters?

[oratorio]

I am trying to establish a pattern in my project for memoized state selection. Specifically I want to be able to memoize the output of state operations as shown below for the sake of performance, like what if offered by reselect for Redux.

const useExpensiveState = (input) => {
    const [value] = useAtom(myAtom)
    return expensiveOperation(input, value);
}

I looked through the options, and it seems SelectAtom and DerivedAtom do offer this, but they are not able to take dynamic arguments. AtomFamily is able to solve this problem, as well as having a pretty good API, but carries the risk of memory leaks.

I considered leveraging useMemo from React to cache output values from 'selector' functions but I thought it would be best to stick with a solution offered by the library.

function useMemoizedSelector<T, R>(
    atom: Atom<T> | WritableAtom<T, unknown>,
    selectorFunc: (...args: [T, ...any[]]) => R,
    selectorArgs: any[] = []): R {
    const [val] = useAtom(atom)
    const memoVal = useMemo(() => selectorFunc(val, ...selectorArgs), [val, ...selectorArgs])
    return memoVal
}

It would be great to know if there's a recommended pattern for this.

[dai-shi]

My recommendation is this:

const useExpensiveState = (input) => {
  const [result] = useAtom(useMemo(() => atom((get) => {
    const value = get(myAtom)
    return expensiveOperation(input, value)
  }), [input]))
  return result
}

selectAtom can work too, but you need useCallback anyway, so doesn't help much.

const useExpensiveState = (input) => {
  const [result] = useAtom(selectAtom(myAtom, useCallback((value) => expensiveOperation(input, value), [input])))
  return result
}

[oratorio]

So after doing a bit more work and thinking about this, I have a few more questions.

Would there be any interest in changes to atomFamily to implement a configurable cache size, so it can be used more like a traditional selector (Or for changes to selectAtom to support arguments in the selector function)?

I understand that atomFamily was inspired by Recoil's own atomFamily, which doesn't seem to be intended to be used as a selector, but it feels like there is room for the framework to support selection with parameters without needing to explicitly manage cache sizes.

Otherwise our approach would be to create a util function that basically does the solution you outlined above with an extra layer of abstraction:

export function useMemoizedAtom<T, R>(
  selectAtom: Atom<T> | WritableAtom<T, unknown>,
  selectorFunc: (...args: [T, ...any[]]) => R,
  selectorArgs: any[] = []
): Atom<R> {
  const memoAtom = useMemo(
    () =>
      atom((get) => {
        const val = get(selectAtom);
        return selectorFunc(val, ...selectorArgs);
      }),
    [...selectorArgs]
  );
  return memoAtom;
}

export const useExpensiveState = (input) =>
  useMemoizedAtom(
    myAtom,
    (value) => expensiveOperation(input, value)
    [input]
  );

[dai-shi]

To my understanding, specifying an ideal cache size is a very hard thing in general, so I would avoid to have an API to encourage it.
If you want to garbage collect unused data in react lifecycle, useMemo/useCallback is the best tool. Extra abstraction seems unavoidable to me.
I would use selectAtom+useCallback, and we still get benefit from react-hooks eslint rules.

const useExpensiveState = (input) =>
  useAtomValue(selectAtom(myAtom, useCallback((value) => expensiveOperation(input, value), [input])))

Alternatively, you could try setShouldRemove in atomFamily, but it's not cache size based, so it may not help.

Also, it's not very hard to create your own version of atomFamily. I would suggest trying it if you want such a feature:

const cache = []
const MAX_SIZE = 10
const myFamily = (input) => {
  const found = cache.find(item => item[0] === input)
  if (found) return found[1]
  const anAtom = atom((get) => expensiveOperation(input, get(myAtom)))
  cache.push([input, anAtom])
  if (cache.length > MAX_SIZE) cache.shift()
  return anAtom
}

[oratorio]

Thank you for your reply. I think I will stab at re-implementing atomFamily.