-
Notifications
You must be signed in to change notification settings - Fork 607
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Ordering] add ability to define order constraints within rank #302
base: master
Are you sure you want to change the base?
Conversation
how does this address #201? im looking for that functionality but dont see how this maps to the ability to incrementally layout a new node to a graph. |
@mx2323 I haven't tested it yet, but after calling |
Are you sure this addresses #112? My understanding is that this adds node order constraints but that doesn't necessary help with outgoing edges. For example: Swapping C and D or A and B won't fix the edges by itself. The correct way is to add an extra crossing between either A's outgoing edges or B's outgoing edges. |
@branpk ah good point, this won't necessarily solve outgoing edges. My understanding is that this PR fixes the second ask of #112 (within same rank):
Thanks for the callout, hope that clarifies! |
@izhan excellent, solved my question. nice |
Does anyone knows a hack to accomplish this? |
Add ability to pass in a list of graph constraints (list of high node vs low node relationships) to influence the ordering of the graph. Useful for picking which way edges go and for making a layout more 'stable' (the onesignal use case is making all branch edges of the same type go the same way). This is essentially this commit by izhan izhan@4b40097 in this PR dagrejs#302 with a couple changes - high/low over left/right plus some type overrides (alternatively could fork definitelytyped and put the changes there)
Add ability to pass in a list of graph constraints (list of high node vs low node relationships) to influence the ordering of the graph. Useful for picking which way edges go and for making a layout more 'stable' (the onesignal use case is making all branch edges of the same type go the same way). This is essentially this commit by izhan izhan@4b40097 in this PR dagrejs#302 with a couple changes - high/low over left/right plus some type overrides (alternatively could fork definitelytyped and put the changes there)
Add ability to pass in a list of graph constraints (list of high node vs low node relationships) to influence the ordering of the graph. Useful for picking which way edges go and for making a layout more 'stable' (the onesignal use case is making all branch edges of the same type go the same way). This is essentially this commit by izhan izhan@4b40097 in this PR dagrejs#302 with a couple changes - high/low over left/right plus some type overrides (alternatively could fork definitelytyped and put the changes there)
Could someone please review and merge the open PRs? It would also be great if we could get responses to the open issues. Thank you! |
Allows for node order constraints like:
Addresses: #112, #201, #251, among others
Related PRs: #263, #252
Usage
Example
Without constraints:
With constraints:
Details
I'm following a suggestion made by @cpettitt in dagrejs/dagre-d3#64 (comment)
To specify the constraints, I'm following the
opts
approach used in #263, but open to suggestions.