no exported class LayoutDagRoot, LayoutDagNode, LayoutChildLink about d3-dag HOT 8 CLOSED

by the way... this link was broken https://erikbrinkman.github.io/d3-dag/

from d3-dag.

This was by design. Dags are supposed to be created with any of the creation functions (connect, hierarchy, stratify), but not created manually, which is why those members were not exported.

Is there a reason why you need to create nodes manually? I'm not overly opposed to exporting them, but I would want to see a compelling argument to. Part of the benefit of "controlling" dag creation is to prevent someone creating a cycle or something else which would break expected invariants around dags.

you also point to the fact that:
import { LayoutDagRoot, LayoutDagNode, LayoutChildLink } from 'd3-dag/dist/dag/node';
will compile in an IDE, but does not work at runtime. I think this is due to the poor way that I export types. It's evolved over time, but isn't great. I think I have a solution though, so I'll address and fix that problem separately.

from d3-dag.

can you provide detailed typescript example/doc/urls of using connect(), hierarchy(), stratify() ?
Can I still control it objets by objets (given that I already have a graph of objects in typescript), or do I need to fully export it in a typescript (json?) array, and import it in one method call.

from d3-dag.

Thanks for pointing that out. I just fixed the documentation which should be up now and should answer your questions. There was an update to typedoc, so unfortunately some of the links in the documentation are going to be broken until I fix it, but it should be pretty easy to figure out where they were pointing.

If you already have typescript objects that look like a dag, then you can use hierarchy which is exported as dagHierarchy() until I resolve the common js / es module stuff. Say for example that you had objects with the following interface:

interface MyObj {
   uniqueString: string;
   nextObjects: MyObj[];
}

then you could create a dag with:

const myDag: Dag<MyObj> = dagHierarchy().id(obj => obj.uniqueString).children(obj => obj.nextObjects)(root)

from d3-dag.

ok, looks good

this also raises another question:
In my typescripts objects, I have several types of objects and several types of ChildLink (LinkData) dependencies.
Is it possible with dagHierarchy() to enrich the method ".children(obj => childObjects)" to have instead ".childLinks(obj => childObjectLinks)" where a childLinkObject would be a pair of object reference and user-defined LinkData .
I would like to use these LinkData attribute to give different style and behavior on rendered graphical elements.

from d3-dag.

Look at the documentation (which unfortunately seems to do a poor job with the typescript annotations, the source is probably a better place to turn). Instead of children you can use childrenData

from d3-dag.

As of version 0.7 (which has some breaking changes), the full build should be pushed, so importing from d3-dag/dist/... should now work in case you really still need LayoutDagNode, although I will caution that it's use still isn't recommended.

from d3-dag.

A new version 0.8 which is effectively 1.0-rc is out. The documentation should be up to date and mostly working, although there are probably a few missing things here and there. Everything is updated, although I did remove the ability to create your own nodes automatically.

Let me know if you're still unable to do what you want. Otherwise I'm going to close this in a week or so.

from d3-dag.