Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question: Object representation of the connections #365

Open
mathantunes opened this issue May 21, 2023 · 6 comments
Open

Question: Object representation of the connections #365

mathantunes opened this issue May 21, 2023 · 6 comments

Comments

@mathantunes
Copy link

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
Copy link
Contributor

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
Copy link

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
Copy link
Contributor

briangregoryholmes commented Jun 23, 2023

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
Copy link

Joshswooft commented Jun 25, 2023

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
Copy link
Contributor

I'm not against that idea.

@Br3nnabee
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants