Difference between useStore and store.getState()

[henryfung3a27]

Introduction

I have been using useStore with zustand/shallow as the comparator to trigger update state. However, I find that I can get the state by store.getState() too.

My store has a data field of type Record<string, object> that could grow pretty big and complex (50 key-value fields on root level with some nested object of depth around 3/4. I don't feel any UI lagging quite yet and zustand can do the task pretty well (thx!).

Question

Are there any difference or drawback when using store.getState()? Suppose I'm trying to read the state only and not calling functions in the store.

[dai-shi]

store.getState() is to read the store state in vanilla. You need to use useStore to have a reactive value in React. In other words, if store.getState() just works, it's good to go.

[henryfung3a27]

Great! Thanks

[gsouf]

@dai-shi I'm wondering in term of performances how the following two examples compare:

function Controls() {
  const increasePopulation = useBearStore((state) => state.increasePopulation)
  return <button onClick={increasePopulation}>one up</button>
}

In this case my understanding is that everytime the store bearStore is updated then the useBearStore will do some computation in order to know whether or not the component should rerender. But it seems quite obvious in this case that this component will never re-render if we assume that the function increasePopulation is never going to change.

So assuming that increasePopulation is never going to change and that we don't need a memoized callback for increasePopulation, then we don't need the reactivity offered by the store hook. We can then change the code above to become:

function Controls() {
  return <button onClick={() => useBearStore.getState().increasePopulation()}>one up</button>
}

Then my understanding is that the component will provide the exact same feature but the useBearStore will not do unnecessary computation as we don't check whether or not the component should re-render. So in theory we have a minor performance improvement. Right?

I tested this in an app using zustand. It works well.

Here is my question: Is it something we can safely do with zustand?

[henryfung3a27]

Not sure if store.getState() will load the entire store into memory everytime under the hood, then select the specific member increasePopulation() and call it. I'm no expert in JS but if so, it's basically a space vs time problem. Not that it wouldn't work, but how you'd prefer it to be done.

In my case for example, I don't feel any performance changes. The only thing is the number of lines of code.

[dai-shi]

So in theory we have a minor performance improvement. Right?

Yes.

Here is my question: Is it something we can safely do with zustand?

Yes.

See also: https://docs.pmnd.rs/zustand/guides/practice-with-no-store-actions

[gsouf]

@henryfung3a27 store.getState() will return the same object as the state value that you have when you do useBearStore((state) => state.increasePopulation). It does not load anything, it just retrieves a reference to the store's state instance. There is no such a thing a "space vs time problem" when doing that, the function increasePopulation will always be the same in either cases. In other terms store.getState() will always return the current state's value with its latest values due to the fact that by nature Zustand is independent of react.

It's mostly a matter of using the library in the way it was intended to be used.

I believe the performance implication will be minimum, but it's always a good thing to know and it might help in some cases.

[kanasva]

I used useMyStore.getState() in a react component to just get the value for each render but not subscribe it.

However, I've just installed React Compiler and its eslint. It warns me:
"Hooks may not be referenced as normal values, they must be called. See https://react.dev/reference/rules/react-calls-components-and-hooks#never-pass-around-hooks-as-regular-valueseslint(react-compiler/react-compiler)"."

And when I pnpx react-compiler-healthcheck it shows:

• "Successfully compiled 101 out of 107 components." for using useMyStore.getState()
• "Successfully compiled 103 out of 108 components." for useMyStore()

I don't know why my components increase from 107 to 108.

To conform with React Compiler, we should not use .getState() directly in React components. Instead, we should call the store as a hook. This will trigger re-renders when the state changes, but auto memoization from React Compiler should help optimise performance (need to test further).

Update:
I just create a function outside the react component to call .getState(), then call that function inside the react component.

function getMyStore() {
  return useMyStore.getState();
}

[tifandotme]

Interesting, I encountered the same issue