Question: Object representation of the connections

[mathantunes]

I started playing around with Svelvet and I couldn't figure out a way to get a representation of all nodes and edges under a certain Svelvet component.

What I have in mind is allowing a user to create nodes and edges as they will and then extract the latest connection state after a click on Save.

Is there a way to get this information?

I expected to be able to retrieve an object as such:

{
    "nodes": [ ... ],
    "edges": [ ... ]
}

With values similar to the ones in the examples:

const initialNodes = [
    {
        id: 1,
        position: { x: 350, y: 50 },
        data: { label: 'input Node' },
        width: 175,
        height: 40,
        bgColor: 'white'
    },
    {
        id: 2,
        position: { x: 350, y: 150 },
        data: { label: 'Default Node' },
        width: 175,
        height: 40,
        bgColor: 'white'
    }
];

const initialEdges = [
    { id: 'e1-2', source: 1, target: 2, type: 'default', label: 'label'},

Is this possible currently?

[briangregoryholmes]

Hey, mathantunes. We're hoping to have native save/reload functionality enabled soon after the next major version release, which should be later this week. The syntax you provided looks like syntax from v6. v6 did not feature two way data binding in this manner and so you would not have been able to save Nodes/Edges unless you were programmatically adding them. Despite the API change, this is also true of v7. That said, this is absolutely a priority for us and I'll let you know as soon as it's live.

In the meantime, the only thing that you aren't able to access in the current version is the connections made by end-users using the UI. Nodes can only be created by explicitly adding additional children to the Svelvet component (whether through conditional rendering, "explicit" rendering or an #each block), so that data should be available to you already. You can also bind to the position prop on the Node component in a read-only manner if you wanted to save the positions. Hypothetically, you could query the DOM to get the current edges, but, again, we should have a native way of enabling this very soon.

[rungdung]

Hey, mathantunes. We're hoping to have native save/reload functionality enabled soon after the next major version release, which should be later this week. The syntax you provided looks like syntax from v6. v6 did not feature two way data binding in this manner and so you would not have been able to save Nodes/Edges unless you were programmatically adding them. Despite the API change, this is also true of v7. That said, this is absolutely a priority for us and I'll let you know as soon as it's live.

In the meantime, the only thing that you aren't able to access in the current version is the connections made by end-users using the UI. Nodes can only be created by explicitly adding additional children to the Svelvet component (whether through conditional rendering, "explicit" rendering or an #each block), so that data should be available to you already. You can also bind to the position prop on the Node component in a read-only manner if you wanted to save the positions. Hypothetically, you could query the DOM to get the current edges, but, again, we should have a native way of enabling this very soon.

Hey @briangregoryholmes, is this on the immediate roadmap? Would love to see it. As i commented on #247, it would be a critical feature to use.

[briangregoryholmes]

This is absolutely the primary feature I'm focused on at the moment, it's just a matter of finding the time and implementing it correctly.

[Joshswooft]

This might also be kinda related to this issue, but I am also attempting this and ended up making my own node store that sits alongside the svelvet one. What I would like to know is can you represent additional information on the node and be able to retrieve it using the built in node store or is my approach by creating a seperate store the correct one for now 🤔

It would be nice if the nodes have a data property or something where I can attach my context specific information to rather than running 2 stores and encountering possible edge cases/sync issues.

[briangregoryholmes]

I'm not against that idea.

[Br3nnabee]

Hey, just wondering where we are on this? Was this ever implemented?