I'm having a problem using the SimulationLinkDatum Type. I made two classes Node and Link that implement SimulationNodeDatum and SimulationLinkDatum. When I go to try and use SimulationLinkDatum typescript says that d.source.x, d.targe.x, etc typescript says that "Property 'x' does not exist on type 'string | number | Node'."
I understand that the SimulationLinkDatum accepts number | string | <T> for the source and target node properties and that if you use number or string that it will be mutated into a SimulationNodeDatum. Is this just something that we have to live with or is there a better way of using these interfaces?
Thanks
class D3Component {
private createPathString(d: SimulationLinkDatum<Node>) {
return 'M' + d.source.x + ',' + d.source.y + 'L' + d.target.x + ',' + d.target.y;
}
}
class Node implements SimulationNodeDatum {
public x: number;
public y: number;
constructor (public id: number) {}
}
class Link implements SimulationLinkDatum<Node> {
constructor (public source: Node, public target: Node) {}
}
As you correctly point out, the TypeScript definitions for d3-force reflect the approach to mutating the node and link data structures inherent in the actual JS implementation.
Specifically, for the SimulationLinkDatum<NodeDatum extends SimulationNodeDatum> interface, the suggested practice is to use a custom type guard, e.g.:
function isNodeObject<T>(node: number | string| T): node is T {
return typeof node !== 'number' && typeof node !== 'string';
}
Then the type narrowing of TypeScript can be used in as usual, e.g. in your case above:
private createPathString(d: SimulationLinkDatum<Node>) {
if (isNodeObject(d.source) && isNodeObject(d.target)) {
return 'M' + d.source.x + ',' + d.source.y + 'L' + d.target.x + ',' + d.target.y;
} else {
return '';
}
}
While this is the most reusable approach, the following two alternatives may be more suitable in some situations:
(1) If it is known that a given code segment will only be invoked on links that have already been initialized, then one may simply cast (<SimNode>d.source).x. Using local variables for the cast node objects may improve downstream readability.
(2) Use the type narrowing directly in an if-clause without creating a re-usable custom type guard.
Given the way the interfaces are currently defined, these are the key ways to access the objects in the mutated properties.