Best Practices for Storing Non-Reactive State in Zustand

[kkshinkai]

Zustand, like React, expects immutable data structures for state management. However, here’s the context of my requirements:

1. Some state updates are triggered by high-frequency operations (e.g., 'onpointermove'), where immutability can lead to significant performance overhead.
2. Some state is unrelated to the UI (not accessed by any selector) and is inherently non-reactive.
3. These states cannot be global because I use React context and Zustand store API, treating Zustand as a local state manager for my components. These states should still reside in Zustand.

Here are two specific scenarios to illustrate why I have this unusual need:

1. In my drawing app, I track an inputs state, including the mouse-down position and current mouse position, for drag and selection calculations. This state updates at a very high frequency but is only needed during certain calculations. I want to avoid selectors unnecessarily re-running due to frequent updates.
2. I manage an undo/redo stack for a history system. During drag operations, the stack is updated frequently, merging transformation records. Since the undo/redo stack is not rendered in the UI, allowing mutable structures would significantly improve performance.

Currently, I use closures in slice creators to handle such scenarios, like this:

export const createCounterSlice = (set, get) => {
  let nonReactiveArray = [];

  return {
    nonReactiveArray, 
    // Non-reactive, accessible by other slices but not intended for selectors.
    // In most cases, it doesn’t need to be exposed here.

    length: 0, 
    // Reactive array length.

    push: (value) => {
      nonReactiveArray.push(value); // Mutates in-place.
      set(state => {
        state.length += 1; // Reactive update with immer.
      });
    },
  };
};

This works but feels misaligned with Zustand’s philosophy. What would be the recommended approach for my use cases in Zustand?

[dai-shi]

What's documented is transient updates.

I think what you are doing is fine as long as you understand it correctly, and I can see that from the comment. But, yeah, I wouldn't put it in the store as you implied.

In most cases, it doesn’t need to be exposed here.

What's the case you need to put it in the store?

[kkshinkai]

Thanks!

What's the case you need to put it in the store?

I put it here because functions in other slices might need to access this value. I haven’t found a good way to represent “slice-private” variables or methods. I usually prefix these with _ or internal_.

[dai-shi]

You could get the array from outside, from the store creator.

export const createCounterSlice = (set, get, arr) => { ... }
// or
export const createCounterSlice = (arr) => (set, get) => { ... }