Sometimes, when calling setFromKeyForLinkData, a single call will set from to undefined instead of the string I provide, and if I call the same method with the same parameters a second time, it does what I ask for. Why is that? Am I missing something? How to make sure that the first call sets the property correctly every time?
Wow, that’s hard to believe, unless there is some exception happening. Can you provide a simple reproducible case that we can debug?
Trying to come up with some possibilities:
Is GraphLinksModel.archetypeNodeData non-null? If it automatically tried to create that node data, there might have been a failure.
Does the “99_9769/99_9767_BlackBox” Node already exist when executing your debug code? If not, I could see the Diagram setting Link.fromNode to null, in turn causing the data.from to be set to undefined. But I haven’t tracked down all of the possibilities there.
I have never used GraphLinksModel.archetypeNodeData so that can’t be the problem.
I think it is the second possibility, because I’m in a pass where I add/remove nodes and re-route links accordingly. I reordered my code to make sure that all nodeData are added to the model before I change link extremities, and the problem went away.
Thanks for your help :) However, I think this behaviour should be mentioned in the docs because it took me a while to find out what was happening.
Also, about the documentation, the type annotations with brackets (Iterable.<Object>) are not rendered correctly (the brackets are not escaped correctly and the browser thinks it’s an HTML tag):
Yes, trying to use references to non-existent node data should work when loading a whole model, but not when incrementally modifying a model.
In other words, your Model.nodeDataArray or GraphLinksModel.linkDataArray can be replaced containing “forward” references, but you cannot do so while making changes afterwards one property at a time. That’s because when replacing the whole array the model knows about potential referents and can resolve them later. But the public API for Models doesn’t let you control how unresolved references can be resolved. That would be a significant complication to the API, which we wanted to avoid.
Yes, we know about the problems with our documentation generator, jsDocToolkit. We’re in the midst of translating the library into TypeScript, so we’ll be addressing documentation generation anew soon enough.