72 happy path first #73
Conversation
| // negative dX indicates connection from future to past | ||
| if (dX < 0 && dY <= 0) { | ||
| return [ | ||
| getDockingPoint(sourceMid, sourceBounds, 'b'), | ||
| { x: sourceMid.x, y: sourceMid.y + DEFAULT_CELL_HEIGHT / 2 }, | ||
| { x: targetMid.x, y: sourceMid.y + DEFAULT_CELL_HEIGHT / 2 }, | ||
| getDockingPoint(targetMid, targetBounds, 'b') | ||
| ]; | ||
| } |
There was a problem hiding this comment.
@nikku Not exactly sure if this is the right approach. I have added the condition when it's a loop (future to past) means dX will be negative and the connection can be either on the same row or row less than the current element (dY <=0).
For reference, It solves this case.
|
@nikku Confused about the strategy of happy path first after Till's comment #50 (comment). Do we consider connections from top or not? |
I consider that we fully understand our strategy, and take it from there. For me "back loop on top" is nothing that I've seen applied in practice, and it makes it harder to understand the happy path. |
* happy path first, rest bottom layout Related to #72
nikku
force-pushed
the
72-happy-path-first
branch
from
3d841eb
to
ebe1c93
Compare
There was a problem hiding this comment.
@abdul99ahad I separated spec and snapshot updates on the PR. This way it was easier to me to review before/after state.
This is a simple, yet effective, change to lead to overall cleaner diagrams, cf. diffs:
Hence, let's move forward with it, and have additional discussions as a follow-up.
Closes #72
Proposed Changes
The primary path will always come first, with secondary connections following below.
Checklist
To ensure you provided everything we need to look at your PR:
@bpmn-io/srtoolCloses {LINK_TO_ISSUE}orRelated to {LINK_TO_ISSUE}