8000 [Question] Storing custom data properties on ElkNode and ElkEdge objects (to be used later during rendering)? · Issue #1131 · eclipse-elk/elk · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

[Question] Storing custom data properties on ElkNode and ElkEdge objects (to be used later during rendering)? #1131

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.

Sign up for GitHub

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

Jump to bottom
Open
IarwainBen-adar opened this issue Mar 12, 2025 · 2 comments 8000
Open

[Question] Storing custom data properties on ElkNode and ElkEdge objects (to be used later during rendering)? #1131

IarwainBen-adar opened this issue Mar 12, 2025 · 2 comments
Labels
question Request for support in using ELK.

Comments

@IarwainBen-adar
Copy link

Is there any documentation available on storing custom properties on ElkNode and ElkEdge objects?

From examining the ELK source and metadata descriptions, and from trial and error within the ELK-Live json-to-elkt converter, I have come to the initial conclusion that custom data property attributes are allowed to hang off the base definition of an ElkNode or ElkEdge object, as in:

{
    id: "n1",
    tokenData: {
        category: "node",
    }
}

But if I try to store custom data properties inside the properties block itself, ELK throws errors:

{
    id: "n1",
    properties: {
        tokenData: {
            category: "node",
        }
    }
}

Is the properties block itself a special case for ELK? I can find very little (if any) mention of the properties block in the ELK API documentation.
@IarwainBen-adar IarwainBen-adar added the question Request for support in using ELK. label Mar 12, 2025
@Eddykasp
Copy link
Contributor

The properties in ELK are where the layout options known to ELK are stored. The parser and library presumably are not happy if unknown or unexpected things end up in there. There are also internal things elk may store there that are not part of the options API so that is also something to keep in mind.

In general if you want to attach stuff to the JSON for use during rendering later, you should be fine attaching additional attributes to the objects as in your example. You just need to be mindful not to use reserved names, but that's not actually a lot. Properties, children, edges, and some more things I can't think of right now. If you look at some more complex examples from the elklive website and convert them to elkj I think that should end up being fairly comprehensive.

It's not really documented anywhere because it's not exactly an officially supported use case. Doing it cleanly would probably require us providing a dedicated attribute to "pass through" data to be preserved on the nodes after the layout. Maybe if someone has time to add this, we'll do it at some point. PRs are always welcome. I think this would be mostly something for elkjs and not Java ELK.

@IarwainBen-adar
Copy link
Author

Thank you for the explanation! That clears things up for me. I'm happy to close this, or leave it open so others with questions about custom property/attribute data might find the answer more easily when searching (I had some difficulty finding information on this topic).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
question Request for support in using ELK.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@Eddykasp @IarwainBen-adar
0