Does pattern changed about using selector in component?

[seanbruce]

Hi, I do remember the document used to describe how to use selectors in components to improve performance:

// selectors don't rely on states or props

const selector = (state) => state.name

function App() {
    const name = useStore(selector);
    // ...
}

or

// selectors do rely on states or props

function App({id}) {
  const selector = useCallback((state) => {
    return state[id]
  }, [id]);
  const state = useStore(selector);
  // ...
}

now those cannot be found in the document.
My question is whether the selector no longer needs to be stable to improve performance. because I used to follow those patterns in my code strictly, if the function stability doesn't matter anymore, I could save a few keystrokes.

[dai-shi]

Thanks for opening a discussion.

In the past, we recommended the use of stable selectors in v3, because we were targeting v4 with useMutableSource at that point.

After that, React deprecated experimental useMutableSource and provides useSyncExternalStore.
For more context:

1. https://twitter.com/TkDodo/status/1427922647401312257
2. useMutableSource and selector stability reactwg/react-18#84
3. useMutableSource → useSyncExternalStore reactwg/react-18#86

Now, zustand v4 is based on useSyncExternalStore, so stable selectors are not necessary. But if you have a stable selector, you can expect the performance is a little more improved.

In summary:

inline selectors are just fine and recommended

const Component = () => {
  const slice = useStore((state) => state.slice);
  // ...

useCallback for lightweight selectors is an extra overhead, and not recommended

const Component = () => {
  const slice = useStore(useCallback((state) => state.slice, [])); // ❌ 
  // ...

Having stable selectors can improve performance, but not very noticeable

const selector = (state) => state.slice; // ✅ 
const Component = () => {
  const slice = useStore(selector);
  // ...

[pastelmind]

That's no longer accurate. The recipes.mdx is a copy of readme.md at once, and not well maintained. Can you open a PR to fix?

Sure.

I edited a new question into my previous reply, which you may have missed b/c you replied so quickly. Could you please check it as well?

[dai-shi]

A related PR https://github.com/pmndrs/zustand/pull/550/files#diff-5a831ea67cf5cf8703b0de46901ab25bd191f56b320053be9332d9a3b0d01d15. We can simply remove the section.

[pastelmind]

Ah, it appears that Zustand delegates selector management to useSyncExternalStoreWithSelector():

zustand/src/react.ts

Lines 35 to 49 in 1dd85fe

	export function useStore<TState, StateSlice>(
	api: WithReact<StoreApi<TState>>,
	selector: (state: TState) => StateSlice = api.getState as any,
	equalityFn?: (a: StateSlice, b: StateSlice) => boolean
	) {
	const slice = useSyncExternalStoreWithSelector(
	api.subscribe,
	api.getState,
	api.getServerState || api.getState,
	selector,
	equalityFn
	)
	useDebugValue(slice)
	return slice
	}

I checked the implementation of useSyncExternalStoreWithSelector() from the use-sync-external-store package. This hook uses useMemo() to compute the next slice, and since the selector is in the dependency array, it will re-run when the selector identity changes. However, a well-behaved selector (or one with an appropriate equality function) would allow React to bail out from re-rendering anyway. The overall cost of invalidating useMemo() would be negligible in light of everything else while rendering.

I also read reactwg/react-18#86 which lead me to reactwg/react-18#84, which gives me hope that the React team is committed to ensuring that selector stability would not become a performance pitfall in the future.

Edit: And the answer to my own question

More generally, does Zustand skip computing the new value across re-renders if the store is unchanged AND the identity of the selector function is the same? Knowing this would provide better insight into whether I should use useCallback() for a particular selector.

appears to be false. Both the genuine and shimmed versions of useSyncExternalStore() calls the selector on every render, regardless of whether it is stable:

https://github.com/facebook/react/blob/ffb6733eefc23e62c1fb94ce7fc442f87255ebd7/packages/react-reconciler/src/ReactFiberHooks.js#L1679-L1682

https://github.com/facebook/react/blob/ffb6733eefc23e62c1fb94ce7fc442f87255ebd7/packages/use-sync-external-store/src/useSyncExternalStoreShimClient.js#L53-L57

So a selector is called on every render regardless of whether it is stable (or memoized). I assume the general advice would be:

1. Don't bother with memoizing selectors in most cases
2. Move expensive computations out of selectors and into your own useMemo()s

[pastelmind]

Relevant discussion here: #658

[dai-shi]

Wow, you investigate it pretty well.

Don't bother with memoizing selectors in most cases

Correct.

Move expensive computations out of selectors and into your own useMemo()s

For single component use case, it's true.
For shared selector across component use case, memoization with reselect, proxy-memoize or such would help.