onNodesChange usage help

[Defite]

Hi everyone! I'm testing strange behaviour in my code with react version of xyflow.

I test dragging perfomance on 100 simple nodes withoud connected edges (arrows). When I use

const [nodes, setNodes, onNodesChange] = useNodesState(initialNodes);

everything is smooth both with devtools opened and closed.

When I use function from my custom Zustand store with this function

onNodesChange: (changes) => {
    set({
      nodes: applyNodeChanges(changes, get().nodes),
    });
  },

dragging becomes laggy (with drops to 2fps and freezes).

My store consists of slices and uses some middlewares like zundo and immer:

export const useEditorStore = create<AppStoreSlices>()(
  temporal(
    immer(
      devtools((...a) => ({
        ...editorSlice(...a),
        ...panelsSlice(...a),
        ...nodeSettingsSlice(...a),
        ...editorControlsSlice(...a),
      }))
    ),
    {
      partialize: (state) => {
        const { nodes, edges } = state;

        return { nodes, edges };
      },
      equality: (pastState, currentState) => {
        const remapNodes = (nodes: Node[]) => {
          return nodes.map(({ measured, dragging, ...node }) => ({
            ...node,
          }));
        };

        return deepEqual(
          { nodes: remapNodes(pastState.nodes), edges: pastState.edges },
          { nodes: remapNodes(currentState.nodes), edges: currentState.edges }
        );
      },
      limit: 50,
    }
  )
);

I tried comment them and use store without them - nothing changed.

I've attached editorSlice as it is too big to show here), but here is the onNodesChange function.

export const editorSlice: StateCreator<
  AppStoreSlices,
  [['zustand/immer', never], ['zustand/devtools', never]],
  [],
  EditorSliceState
> = (set, get) => ({
  nodes: [],
  onNodesChange: (changes) => {
      set({
        nodes: applyNodeChanges(changes, get().nodes),
      });
    },
    ...
});

Why it could possibly so dramatically drop in perfomance?

[Defite]

xyflow-zustand-repro-github.zip
I've attached code for reproducing this strange behaviour. My motivation to use zustand is because I'm using undo/redo with it and store some data there. I can rewrite my code to use redo/undo without making use of zustand, but it's rather strange behavior.

[MILLERMARRU]

Immer is a contributor here but I'd bet the bigger cost is zundo's equality function, not immer's producer. React Flow fires onNodesChange with a position change on every pointer-move tick during a drag, so with useNodesState that's a plain array replace each tick, cheap. Through your store, every one of those ticks goes through set() -> immer's produce (proxy + structural clone over your whole slice) -> then zundo's temporal middleware intercepts that same set() and, unless told otherwise, evaluates your custom equality function to decide whether to push a new history entry. Your equality does a full deepEqual over nodes and edges with a remap on every node first, that's O(n) deep comparison running on every single mousemove-driven position change, at 60+ times a second that adds up to the 2fps you're seeing well before immer's own overhead becomes the bottleneck.

zundo has a documented pattern for exactly this, pause history tracking for the duration of the drag, then resume and commit a single entry at the end:

const { pause, resume } = useEditorStore.temporal.getState()

const onNodeDragStart = useCallback(() => {
  pause()
}, [])

const onNodeDragStop = useCallback(() => {
  resume()
  // one more set() here so this final position gets recorded
  useEditorStore.setState((s) => ({ nodes: s.nodes }))
}, [])

<ReactFlow
  onNodesChange={onNodesChange}
  onNodeDragStart={onNodeDragStart}
  onNodeDragStop={onNodeDragStop}
/>

While paused, zundo's wrapped set short-circuits before running your equality function at all, so the deep compare only runs once per drag (on the final commit) instead of once per frame. If you'd rather not touch drag start/stop handlers, handleSet with a throttle wrapper is the other documented option and gets you most of the same win with less wiring:

temporal(config, {
  handleSet: (handleSet) => throttle(handleSet, 200),
})

I'd still keep the pause/resume version for drags specifically though, throttling means you're still running the deep equality every 200ms during the drag rather than not at all, and you'd lose fine-grained history entries you might actually want elsewhere in the app.