I am evaluating GoJS by trying to recreate some in-house stuff using code based on the Dynamic Ports sample, which is the closest to our use case.
Easiest way for me to do this is to put the code into our React app on a separate page, so I’ve done exactly that. I merged the React sample with the Dynamic Ports sample, which required a few adaptions but was straight forward. Migrating our objects into nodeDataArray was very easy using a few new go.Bindings.
But when I got the node ports created I see my sample is not behaving as the Dynamic Ports sample. It looks like it uses the default link instead of the CustomLink in the code. I can drag a new link from one port to another, and it snaps to the ports just fine. But when I release the mouse the created link does not go between the ports I pointed to, it goes go from node center to node center.
There are three pieces of code that are involved AFAICS:
I have verified that CustomLink() itself gets called when the diagram is created, but then something is missing in the inheritance because findSidePortIndexAndCount is never called when I create links.
Any tips on how to get this hooked up right would be helpful!
Good – you actually did read the documentation and were able to solve that problem on your own.
Regarding making use of the CustomLink class, you have to make sure that the link template uses your CustomLink class instead of the standard go.Link class.
Yes I made CustomLinks work as well, but they are not pretty. I tried some improvements to the algorithm, but I am not understanding well how the results of computeEndSegmentLength are actually used because it seems rather random, sometimes the angled line comes in at this distance and sometimes another, and sometimes it makes a little loop :-(
Those loops happen because the nodes are too close to each other, so there isn’t room for the links to be routed in the normal manner for that Link class.
If you adjust the routing:
var info = this.findSidePortIndexAndCount(node, port);
var idx = info[0];
var count = info[1];
if (port._side == "top" || port._side == "bottom") {
if (otherpt.x < thispt.x) {
return 2 + idx * 4;
} else {
return 4 + (count - idx - 1) * 4;
}
} else { // left or right
if (otherpt.y < thispt.y) {
return 2 + idx * 4;
} else {
return 4 + (count - idx - 1) * 4;
}
}
I get this:
If this is not the kind of routing that you wanted, please describe it.
That is pretty good, the result is certainly OK when releasing a node after moving it.
But during the drag the rubber-bands are flashy and jump around a lot, making it hard to see what the final result will be.
We are just doing an evaluation here, so no need to waste time improving at this point.
But I’d like to ask: Should we decide to purchase a license, is this a thing you would be willing to support us with solving?
Try decreasing the magnitude of the computed end segment length – I suggest reducing the multiplier of 4 to 3 or 2. Maybe also reduce the 2+ and 4+ to smaller numbers, perhaps zero and 2+, respectively.
[EDIT] The problem might be that the value returned by computeCurviness is too large given how close the end segments are to each other. I think this is a bug, so we’ll investigate it.
