Comments (4)
This is an interesting idea, and am open for discussion about how best to do this.
In terms of what you suggested, it's only really useful if you collect them into a list or some structure to keep the casting. The problem with that is that then this can happen:
const list = this.dag.descendants().map(node => {
assert(isLayoutedNode(node));
return node;
});
for (const node of dag) {
node.x = undefined;
}
list[0].x; // has type `number`, but is `undefined`
Alternatively if you want to just use the x value, then your example can be done without any aliases or type guards with:
const list : number[] = this.dag.descendants().map(node => {
assert(node.x !== undefined);
return node.x;
});
If you look at old versions of the library (~0.4.0) sugiyama
actually returned a cast of the current dag indicating that it was indeed laidout, e.g. x and y were also defined.
There was a problem getting this to work well. The way I originally implemented used polymorphic this, so that the children were "guaranteed" to be the same type, and therefore laidout. This proved to be more of a headache than it helped, so I got rid of it with a rewrite at some point, because getting types to work with polymorphic this. It also still has the same aliasing problem highlighted above.
Currently I just decided that typescripts non-null assertion was the way to go. It's simple, as safe as a type cast, and has no runtime overhead. Checking works, but if it's happening all the time it's wasting a lot time checking stuff we know to be true.
This ultimately leaves me thinking that exporting that type guard seems a little shallow and it's also pretty trivial to write if its useful to you. However, needed to do it still seems less than ideal. I see two potential routes, I'm not sure either is inherently worth doing.
- There could be a dag / dag node utility class that wraps an existing dag instance and just checks property reads to guarantee that they're set in the underling dag. This would need to run each access, but would prevent you from writing it each time.
- Remove x and y from dag, and instead have a subclass that does have x and y. Then
unsugify
can be set to just create that dag copy with guaranteed values. This prevents aliasing issues, and prevents having to check, but does require a copy and importantly delinks the returned dag from the input dag.
Thoughts?
from d3-dag.
Thoughts?
Not really, in my mind, you ask yourself the right questions ! :)
But that say I would be quite happy with option 2
from d3-dag.
I know it's been a long time since I last responded to this, I've been working on some massive rewrites to allow things to be more dynamic.
For many of the reasons outlined above, I don't think it really makes sense to add a new type definition. Originally I did work on a version that returned a new graph via unsugify. This would be fine the way the library currently works, but with the dynamic use case it makes things much more complex to still maintain d3 data binding, so I ultimately scrapped it. What I've chosen to go with is two separated properties:
- a raw property that can be undefined called
ux
anduy
- a corresponding getter and setter that only accepts numbers, and raises an exception if the properties are
undefined
This isn't ideal in that is still requires runtime knowledge that the dag has been laid out, but you now no longer need non-null asserts, and it gives freedom in interface, e.g. you can still use ux and uy if you want to be safe.
Does this address your use case, or do you think there is still a better solution out there?
from d3-dag.
This standard is now implemented in the prerelease. x and y are always numbers, but will throw if the underlying ux or uy is undefined.
from d3-dag.
Related Issues (20)
- Basic TypeScript type check error HOT 6
- Tips for writing my own layering HOT 2
- General question about node ordering HOT 2
- Specific key order appears to cause decrossOpt to hang HOT 4
- TS: Errors with typescript version 4.9.4 HOT 3
- example code not runable HOT 4
- How to plot a horizonal sugiyama graph HOT 1
- Guidance on Implementing Radial Drawing with d3-dag's Sugiyama Algorithm HOT 3
- Implement Brandes/Köpf Coordinate Assignment
- Expand d3-dag to handle multiple paths from parent->child HOT 4
- Dynamic nodeSize? HOT 1
- TS, export SugiNode<NodeDatum = unknown, LinkDatum = unknown> ? HOT 3
- Possible linking bug in docs HOT 3
- elkjs, external layout algorithms? HOT 1
- is it possible to establish node order explicitly in grid? HOT 8
- Support for TypeScript <4.5
- How to extend DagNode in vanilla js? HOT 6
- Error: size of dag to decrossOpt is too large and will likely crash instead of complete, enable "large" grahps to run anyway HOT 9
- Layout direction HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from d3-dag.