Reduce selector calls by subscribing directly to parts of state?

[beorn]

Hi,

I have an app with a lot of components and I would like to make it as performant as possible, i.e., avoiding unnecessary re-renders and selectors calls altogether.

I know I can rewrite the app to use atoms/signals (or bridge into jotai with atomWithStore) so that components can subscribe to individual atoms/signals — but is there a canonical way to do this in zustand?

For example:

const useCounters = create((set, get) => ({ counter1: 0, counter2: 0 }))

function Counter1() {
  const c1 = useCounters(state => state.counter1)
  return <p>{c1}</p>
}

function Counter2() {
  const c2 = useCounters(state => state.counter2)
  return <p>{c2}</p>
}

Is there a way to ensure that Counter1 is not re-rendered and its selector function isn't even called if counter2 is updated? Imagine I have 10,000 Counter2 components — I'd like for them not to do any work if state.counter1 is updated, but to my knowledge they will each have at least their selector functions run.

I could imagine something like:

function Counter2() {
  const c2 = useCounters.subState().counter2
}

[dbritto-dev]

@beorn you are looking for useShallow or shallow, you could read about those on apis, and hooks sections

[beorn]

@dbritto-dev As far as I understand, even in this case, all of the 10,000 Counter2 components are listeners to the entire store state, so Zustand would have to do work to determine whether they should re-render, no? It has to iterate through 10,000 selectors and see if anything changed, on every store change. I'm trying to short circuit this work so the Counter2 components listen directly to state.counter2 — there's no need to do any work related to them (involving iterating over 10,000 objects) if state.counter2 didn't change.

[dbritto-dev]

@beorn lmk if that helps, you can run some benchmarks with useStore and compare useSelector with useStore

[beorn]

@dbritto-dev I'm sure my bad, but I don't quite understand what your code does? I guess in any case, since it does a store.subscribe inside of useSelector there's still going to be some performance overhead for every component whenever the store updates, no matter if they don't use any of the state that was changed?

I guess I could just create a separate store for each counter too. I also found some interesting functions over on jotai-zustand, and asked for some help in an issue there: jotaijs/jotai-zustand#7

[dbritto-dev]

@beorn does the same as useStore but cache previous values using shallow at useSyncExternalStore level instead of component/hook level

[beorn]

@dbritto-dev Ok, that's cool, but I guess there's still per-component overhead since there's a store.subscribe in there? Perhaps it'd be possible to add a level of subscriptions — you could have a more static set of 'selectables' that subscribe to the store, but components can subscribe to the selectables directly so there's only overhead if their selectable changes? (I guess it'd be like creating an atom derived from the store value, and subscribing to the atom. That's why I thought the jotai-zustand package looked interesting.)

[dbritto-dev]

@beorn sure, it's possible. yeah, jotai-zustand is cool too.