A suggestion for decorating nodes
- Dominant language
- JavaScript
- Stars
- 3.9k
- Forks
- 418
- PR merge metrics
- No merged PRs in 30d
Description
Hello,
I have an interactive graph which populate data from one service (A) and decorate nodes from another (B).
My problem is that I am having issues with chaining callbacks from A and B, and I wonder if there is another way to delegate decoration to a listener of the whole graph.
In my mind I would like to have a smooth responsive graph, and images (decorations) will be populate when are ready.
I am having erratic behavior in my code, I think for delay due to async call of getting info.
Here a pseudo-code:
getNeighbors (parent) {
for c in children {
graph.addLink(parent,c);
//to update node info
~~graph.addNode(c,callbackToA);~~
graph.getNode(c).data = {my property: myvalue}
//to decorate
decorate(c,callbackToB);
}
}
When I render the graphics
graphics.node(function (node) {}
it happens that node.data is undefined,
althought when I look at the graph in the web console, that is after the graph is rendered, I see that data is actually updated.
I am looking at a way to be sure to render the graph only when all information from source A, B is loaded, or alternatively place nodes and links and then update new info while it get fetched.
I wonder if the library there is a lister observer of graph element, so that I could do:
for each new node:
decorate(c,callbackToB);
could you give comments if this is a good idea?
could you give some suggestions for implementing it?
I am also experimenting with promises, but I would like to get a clearer idea first.
thank you!
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by tracing the graph.addNode, graph.getNode, graphics.node, and decorate callback entry points described in the issue. Check how asynchronous updates are observed during rendering and whether a whole-graph listener is already exposed. Done means the supported approach for loading or updating node decorations is clear and covered by the relevant behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- data-visualization
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100