Get cluster objects not using dark power.

[AndrewMut]

Hello, is there any possibility to get cluster nodes in similar way like regular nodes (data.nodes.get())? My case is to get all visible nodes on network. I am getting this info from here network.clustering.body.nodeIndices and it's seems to be a bit wrong.

[wimrijnders]

Wrt to title, I'm inclined to reply with Game of Throne[I] references , but I shall resist.

nodeIndices being wrong: that may well be possible, there is a lot about clusters that is going to be fixed in the next release (already merged to develop branch). But can you nevertheless explain what looks a bit wrong to you?

I can image it looking a bit wrong if you have clustered clusters, nodeIndices is the list of visible nodes, clusters or otherwise. Anything within a cluster, including other clusters, will not be in that list. Is this perhaps the scenario you're in?

As to getting all the clusters, since you hacking into the Network instance anyway (is that what you mean by 'dark power'?), the best was to do it is to iterate over network.body.nodes and filter out the clusters by testing if member isCluster is true per instance.

---

[I] Or Legion, or Midnight, Texas, or Day Watch....too many to choose from.

[AndrewMut]

But can you nevertheless explain what looks a bit wrong to you?

My app is on production already and I am afraid that non public API could be changed due to the internal use, so my logic will become incorrect easily.

Is this perhaps the scenario you're in?

It is. But it's dirrectly what I need. I'm adding custom elements dirrectly to that items. It fits perfect.

[I] My mistake, it should be dark force.

[wimrijnders]

My app is on production already and I am afraid that non public API could be changed due to the internal use, so my logic will become incorrect easily.

I can appreciate that. But I'm afraid that that doesn't answer the question as to why nodeIndices looks a bit wrong.

Also a bit scary, circumventing the API! But I'm quite sure that the behavior of nodeIndices has not changed.

It is.

You mean, you have clusters within cluster?

But it's directly what I need. I'm adding custom elements directly to that items. It fits perfect.

OK, your call. If it works for you then there's no problem. Only I don't think I can offer much support, if any, if things don't work out.

---

OK, so I'll have to resist using Star Wars references.

[AndrewMut]

But I'm afraid that that doesn't answer the question as to why nodeIndices looks a bit wrong.

Itself looks fine but using of it in that way looks wrong. But if You sure that the behavior of nodeIndices won't chang, everything should be good.

Thank You for your help!

[wimrijnders]

Aah, OK, then I misunderstood. The functionality of nodeIndices has not changed, so you should be good.

Also, the description of determining the clusters still applies. You can get the node indices from node.clustering.nodeIndices and use these to check if a given node is a cluster with network.body.nodes[nodeIndex].isCluster === true.

Ah, you closed already. I hope this comment is somewhat still of use.

[AndrewMut]

@wimrijnders Thanks, that will help as well. Because for cluster I use another custom drawn elements.

[wimrijnders]

'custom drawn': Any reason you can not use beforeDrawing() and/or afterDrawing() for this?

[AndrewMut]

I use afterDrawing(). May be You remember I was asking while ago about drawing custom elements.

So now I'm use it but I should draw "+" for cluster nodes and "-" for regular nodes. If I am using data.nodes.get() it will draw for everething except cluster nodes, if just using network.body.nodes it will apply custom elements even to collapsed (hidden) nodes.

network.on("afterDrawing", function(ctx) {

        var fullListOfNodesForCustomDraw = [];

        fullListOfNodesForCustomDraw = network.clustering.body.nodeIndices;

        angular.forEach(fullListOfNodesForCustomDraw, function(value) {
          var radius = 10;
          var nodeId = value;

          var nodePosition = network.getPositions([nodeId]);
          var xIcon = nodePosition[nodeId].x + 0 * radius;
          var yIcon = nodePosition[nodeId].y + 2 * radius;

          ctx.strokeStyle = '#lime';
          ctx.lineWidth = 2;
          ctx.fillStyle = '#grey';
          ctx.circle(xIcon, yIcon, radius);
          ctx.fill();
          ctx.stroke();

          ctx.moveTo(xIcon, yIcon - radius / 2);
          ctx.lineTo(xIcon, yIcon + radius / 2);
          ctx.moveTo(xIcon - radius / 2, yIcon);
          ctx.lineTo(xIcon + radius / 2, yIcon);
          ctx.stroke();
        });

[wimrijnders]

AAh, right! You want to use afterDrawing() on cluster nodes, but it doesn't get called for them.

Now that looks like an oversight. I'm going to check the logic on this. We may need to reopen this issue.

I see now where you're going. That's why you need the cluster nodes. OK, I'm going to think now about how you can get them in a 'legal' manner.

[AndrewMut]

Thanks, will be waiting for the news.

[wimrijnders]

OK, this might look silly, but it's a short, simple solution:

  var ids = Object.keys(network.getPositions());  // id's of all visible nodes, including clusters
  // Say that ids[4] is a cluster id
  network.isCluster(ids[4]);   // ==> true

I see you are actually using getPositions() in the example code. This thing might simplify things.

---

So this is just API calls. You will be returning from The Dark Side!

[AndrewMut]

@wimrijnders , Thank You, it's really so. I don't know why I didn't try in that way.

[AndrewMut]

So we can close that issue?

[wimrijnders]

😁 Don't worry about it, shit like this happens all the time. I'm very sure I feel a lot stupider than you at the moment because of this.

Yes, time to close. Until next time!

[AndrewMut]

@wimrijnders , good that You mentioned this issue, subscribed on it. Also waiting for fix of widthConstraint since it was going to infinity loop.

[wimrijnders]

Infinite loop has been fixed: #3228. But you probably know that, you're just waiting for it.
However, there still appear to be issues with the width calculation: #3517.