OpenFn / lightning

OpenFn/Lightning ⚡️ is the newest version of the OpenFn DPG and provides a web UI to visually manage complex workflow automation projects.
https://openfn.github.io/lightning/
GNU Lesser General Public License v3.0
129 stars 35 forks source link

Edges/paths tend to overlap on the canvas #2366

Open christad92 opened 2 months ago

christad92 commented 2 months ago

As the workflow in a canvas grows with more edges and paths, we have situations where edges and paths overlap as shown in the video below.

https://www.loom.com/share/cbd61186553a482e86b8cc4e6dd59cf7?sid=216dfec4-4065-4c8a-9499-1c18a976c869

There are two potential ways we can do this:

  1. Have a collision detection for paths and edges and use that to ensure they don't overlap.
  2. Allow users to manually arrange edges on the canvas. This way, we can store the x/y positions of each edge.
christad92 commented 2 months ago

@josephjclark you might find this to be interesting. https://github.com/tisoap/react-flow-smart-edge

josephjclark commented 2 months ago

On the left, our production layout with forked dagre. On the right, the dagre fork removed:

image

Uh oh.

What our dagre fork does is disable the "optimal order heuristic". Which, clearly, is designed to minimize edge crossings.

We switched it off because it makes the chart significantly less stable when adding and removing nodes.

josephjclark commented 2 months ago

Unfortunately I can't reproduce Aisha's exact chart. I can produce the same problem on smaller charts, but on her chart it's working fine for me.

I have noticed that inconsistent edge (edges which don't connect to anything) cause weird layouts in my local testing - I wonder if Aisha has a ghost edge in her workflow?

Otherwise I suspect there's something to do order in which nodes are added (or maybe removed), or in the node id patterns maybe, which is triggering the problem

josephjclark commented 2 months ago

@AishaHassen I am struggling to reproduce your issue precisely. I suspect an integrity issue in the workflow itself.

Is it possible to give me access to the project so I can inspect it? Or are you able to download the project.yaml and send that to me?

AishaHassen commented 2 months ago

Hey @josephjclark, seems you already have access to the project. Here is a link to the workflow

josephjclark commented 2 months ago

I've looked closely at the snapshot containing the error. The chart data seems fine - no errant links.

josephjclark commented 2 months ago

Alright, @christad92 @AishaHassen, I am going to admit defeat on this.

First of all, I can't really reproduce the case. I can't work out what triggered that overlap. I've tried and tried but any workflow I create lays out reasonably well. The only time I've seen the exact issue is when I add a "broken edge" to the workflow, but that doesn't even seem to be the problem in Aisha's snapshot.

I was hoping to make some small changes to the layout algorithm to give us a bit more control and stability. But any effort there is going to take weeks of full-time development to pay off. It's just very complicated software.

I've raised #2380 to allow manual ordering of nodes. I think this will take weeks to implement.

If this is happening a lot in the wild, I can restore the optimization that we previously disabled. This will result in better layouts, but while adding new nodes the chart will jump and flip around like a mad thing. I do not recommend this. I have experimented with ways of making the chart more stable, but I haven't landed on solution. Again, I think it'll take weeks to adjust the layout algorithm to only change node order when it really really has to.

I am going to spend the afternoon on #2358, which will highlight all of a node's edges when the node is selected. This won't fix the problem, but it does mean that if there IS an overlap, it'll be easy to detect. I don't have much time left to work on this though. I'm hoping it will be quick.

Let's keep this issue open and continue to track workflows which demonstrate the problem.