Replies: 8 comments 24 replies
-
|
I think that it is a good idea to have separate props for nodes and edges. At least for my use-case I am storing nodes and edges separatly and combine them to one array for passing it to the props of the flow. |
Beta Was this translation helpful? Give feedback.
-
|
This would be amazing for my use case. I'm using React Flow as a part of a larger app where nodes mean something beyond just on the canvas. In our use case clicking a node lets you configure that node somewhere else. To manage that, I'm attempting to store the source of truth of all nodes outside React Flow's state. This means when a node is added to the external state, a new node is added to React Flow and when a node in React Flow gets removed, moved, updated, the external state must be updated to match. The "syncing" of states I'm trying to do would be much easier with callbacks just representing element changes. An example of where the current implementation falters is having multiple nodes selected and moved, I'm relying on the onNodeDragStop callback to update external state when a node is moved, but this doesn't work for multiple selected nodes (as the callback is only called on one), or probably for "Auto-Aligning" nodes (haven't tried, but don't see why the drag callback would be called in that case). |
Beta Was this translation helpful? Give feedback.
-
+1 for this for sure-- This is the main limitation I've had to contending with-- that there is internal data hidden away inside redux stores and the a) Give me an easy way to prevent React Flow from updating position on node drag (getting weird race conditions when I attempt to update the position myself on node drag) Your proposal would increase the interoperability of the library and I think that's good for the library in the long run-- even if the change is not backwards compatible. As for an API.. something like this I would assume-- forgive any glaring errors, I'm quite tired. export type elementChange<T = any> = {
before: FlowElement, // Before element state
after: FlowElement, // After element state
changedKeys: Map<string, any> // A map from each changed key to its new value, for ease of access
};
ReactFlowProps.onElementsChange?: (changedElements: elementChange[]) => void; |
Beta Was this translation helpful? Give feedback.
-
|
I imagine that one of the newer state libs like recoil/jotai/hookstate will make it fairly straightforward for you to provide hooks to subscribe to / update internal state more easily. |
Beta Was this translation helpful? Give feedback.
-
|
Would love to help make the transition to controlled nodes and edges happen! Maybe it could be opt-in and shipped experimentally for now, so that it's not a huge breaking change and can be iterated on? (ie. the same way React form elements can be controlled or uncontrolled) |
Beta Was this translation helpful? Give feedback.
-
|
I am currently refactoring the node and edge handling and the internal/external state handling. The current API looks like this: const [nodes, setNodes] = useState<Node[]>(initialNodes);
const [edges, setEdges] = useState<Edge[]>(initialEdges);
const onNodesChange = useCallback((changes: ElementChange[]) => {
setNodes((prevNodes) => applyNodeChanges(changes, prevNodes));
}, []);
const onEdgesChange = useCallback((changes: ElementChange[]) => {
setEdges((prevEdges) => applyEdgeChanges(changes, prevEdges));
}, []);
return (
<ReactFlow
nodes={nodes}
edges={edges}
onNodesChange={onNodesChange}
onEdgesChange={onEdgesChange}
/>
);With this change you get notified when a node (or multiple nodes) get dragged, selected or removed. The |
Beta Was this translation helpful? Give feedback.
-
|
Hi @moklick, I didn't get a chance to try out the development version this week; hopefully, I will be able to spend more time next week to gain some hands-on experience on V10 branch. Based on reviewing the changes, I have a few questions/observations: A. Using the The hooks are very convenient, especially for new users, and should be included as the default example. I am wondering if the hooks can further "store" the default B. The C. With the overhaul of internal states API, how would the user be able to obtain the |
Beta Was this translation helpful? Give feedback.
-
|
@datoslabs @mikebarkmin @lostfictions @ambroseus @meatflavourdev (I hope it's ok when I ping you here, if not just let me know). Besides the new way of having an controlled React Flow component we might also add the possibility to create a uncontrolled component by passing Update: For updating the nodes and edges we will add a You can find an example that uses all the new features here: https://github.com/wbkd/react-flow/blob/v10/example/src/DefaultNodes/index.tsx What do you think about this? |
Beta Was this translation helpful? Give feedback.

Uh oh!
There was an error while loading. Please reload this page.
-
From elements to nodes and edges
At the moment there is a lot of uncertainty about handling elements (nodes and edges). The problem is that React Flow stores and updates some values like the position, width, height and handles internally that are not changed in the elements array that you pass to React Flow. It would be much clearer if we would use a controlled
elementsprop in combination with anonElementsChangehandler to pass the changes (dragging, selecting, removing) to your elements array.Now that we are speaking about breaking changes I thought that it would be a good time to separate nodes and edges and don't use the elements array anymore but
nodesandedgeswithonNodesChangeandonEdgesChangehandlers.That's the idea for now. We will think about it and discuss pros, cons and the specific api changes here.
Beta Was this translation helpful? Give feedback.
All reactions