Clarification needed on applyNodeChanges/applyEdgeChanges deprecation and replacement

[ken-kuro]

Summary

The applyNodeChanges and applyEdgeChanges functions from useVueFlow() are marked as deprecated in the TypeDocs, but the suggested replacement is unclear and not well documented.

Current Deprecation Message

From the TypeDocs:

@deprecated — Use the store instance call applyChanges with template-ref or the one received by onPaneReady instead.

Issues with Current Documentation

1. "store instance" - What specific store instance is being referenced? Is this Vue Flow's internal Pinia store?

2. "template-ref or the one received by onPaneReady" - How exactly should this be implemented? There are no examples showing this pattern.

3. No migration examples - The current controlled flow documentation still shows using the deprecated functions.

Current Working Pattern (Deprecated but Functional)

const { applyNodeChanges, applyEdgeChanges, onNodesChange, onEdgesChange } = useVueFlow()

onNodesChange((changes) => {
  // Validate changes
  const validatedChanges = validateChanges(changes)
  
  // Apply using deprecated method (but it works!)
  applyNodeChanges(validatedChanges)
})

Questions

1. What is the correct replacement pattern? Can you provide a complete working example?

2. What is the "store instance"? How do we access it?

3. How does the onPaneReady approach work? Can you show the template-ref pattern?

4. Timeline: When will these deprecated functions be removed? Is there a migration guide planned?

Context

This is blocking developers who want to implement controlled flows with proper change validation (confirm delete dialogs, etc.). The current deprecation warnings make it unclear whether our implementations will continue working.

Requested Actions

• Provide clear documentation with working examples of the new pattern
• Update the controlled flow guide to show the non-deprecated approach
• Consider creating a migration guide
• If the new pattern isn't ready, consider removing the deprecation warnings temporarily

Thank you for maintaining this excellent library!

[ken-kuro]

Hi, just wanted to follow up on this.

I found another discussion (#1556) where the maintainer, @bcakmakoglu, mentioned to ignore the deprecation warning for now. That's helpful, but my question is a bit deeper and more about the correct architectural pattern when using a controlled flow with an external state management library like Pinia.

After a lot of trial and error, the only reliable pattern I've found that keeps the UI in sync with an external store (especially for history/undo/redo) is a two-step process inside the change handlers:

1. Call applyNodeChanges / applyEdgeChanges from the useVueFlow() hook to update the component's internal state and guarantee a UI update.
2. Call the applyChanges utility function from @vue-flow/core to calculate the new state for our external Pinia store.

Here is a simplified example of the pattern we are using:

import { useVueFlow, applyChanges } from '@vue-flow/core';
import { useMyStore } from './store';

const { onNodesChange, applyNodeChanges } = useVueFlow();
const store = useMyStore();

onNodesChange((changes) => {
  // 1. Update the component's internal state for UI rendering
  applyNodeChanges(changes);

  // 2. Update the external Pinia store's state
  store.nodes = applyChanges(changes, store.nodes);

  // Now the store can be used for history, persistence, etc.
  store.saveToHistory();
});

My question is: Is this two-step pattern the officially recommended way to manage a controlled flow with an external state store?

It feels a little redundant to call two separate functions for what seems like one logical operation, so I wanted to confirm if this is the intended design or if there's a more streamlined approach we might be missing.

Thanks again for the great library!