[6067] Add support for relative position bending points for edges

[frouene]

Bug: #6067

Pull request template

General purpose

What is the main goal of this pull request?

• Bug fixes
• New features
• Documentation
• Cleanup
• Tests
• Build / releng

Project management

• Has the pull request been added to the relevant project and milestone? (Only if you know that your work is part of a specific iteration such as the current one)
• Have the priority: and pr: labels been added to the pull request? (In case of doubt, start with the labels priority: low and pr: to review later)
• Have the relevant issues been added to the pull request?
• Have the relevant labels been added to the issues? (area:, difficulty:, type:)
• Have the relevant issues been added to the same project and milestone as the pull request?
• Has the CHANGELOG.adoc been updated to reference the relevant issues?
• Have the relevant API breaks been described in the CHANGELOG.adoc? (Including changes in the GraphQL API)
• In case of a change with a visual impact, are there any screenshots in the CHANGELOG.adoc? For example in doc/screenshots/2022.5.0-my-new-feature.png

Architectural decision records (ADR)

• Does the title of the commit contributing the ADR start with [doc]?
• Are the ADRs mentioned in the relevant section of the CHANGELOG.adoc?

Dependencies

• Are the new / upgraded dependencies mentioned in the relevant section of the CHANGELOG.adoc?
• Are the new dependencies justified in the CHANGELOG.adoc?

Frontend

This section is not relevant if your contribution does not come with changes to the frontend.

General purpose

• Is the code properly tested? (Plain old JavaScript tests for business code and tests based on React Testing Library for the components)

Typing

We need to improve the typing of our code, as such, we require every contribution to come with proper TypeScript typing for both changes contributing new files and those modifying existing files.
Please ensure that the following statements are true for each file created or modified (this may require you to improve code outside of your contribution).

• Variables have a proper type
• Functions’ arguments have a proper type
• Functions’ return type are specified
• Hooks are properly typed:
  • useMutation<DATA_TYPE, VARIABLE_TYPE>(…)
  • useQuery<DATA_TYPE, VARIABLE_TYPE>(…)
  • useSubscription<DATA_TYPE, VARIABLE_TYPE>(…)
  • useMachine<CONTEXT_TYPE, EVENTS_TYPE>(…)
  • useState<STATE_TYPE>(…)
• All components have a proper typing for their props
• No useless optional chaining with ?. (if the GraphQL API specifies that a field cannot be null, do not treat it has potentially null for example)
• Nullable values have a proper type (for example let diagram: Diagram | null = null;)

Backend

This section is not relevant if your contribution does not come with changes to the backend.

General purpose

• Are all the event handlers tested?
• Are the event processor tested?
• Is the business code (services) tested?
• Are diagram layout changes tested?

Architecture

• Are data structure classes properly separated from behavioral classes?
• Are all the relevant fields final?
• Is any data structure mutable? If so, please write a comment indicating why
• Are behavioral classes either stateless or side effect free?

Review

How to test this PR?

Please describe here the various use cases to test this pull request

• Has the Kiwi TCMS test suite been updated with tests for this contribution?

[mcharfadi]

I have an issue reproducing the case #6067
with several child nodes.
Also note the weird lines at the left of the node

bending_points_1.mp4

I'm not sure the issue #6086 should be linked, when creating an edge on self, the handles are still placed where I did not click.

20260310-0908-46.8381964.mp4

[frouene]

Actually, it wasn't the right bug, it was #6085.

[mcharfadi]

https://github.com/user-attachments/assets/db273b8f-82fc-4bf8-b51f-38fe6fc4e56b
If I move the node quickly I can change the position of the bending points.
I suspect that this behavior would be easier to reproduce with a diagram with more elements.

[mcharfadi]

What's the use of this moving property ?
Is it only used in useDropNodes ?

How would this work if we're moving a node an we receive another payload from another user ?

I feel like this property should be local only and not change when converting the diagram.

If the current moving property does not reflect the nodes that are actually moving we might want to better update this property when receiving a NodeChange from ReactFlow.

[frouene]

Yes it's only used in useDropNodes, I need this information to know if the node move even it's not an actual move, like for child node.
I used it like the other datas needed for useDropNodes: isDraggedNode, isDropNodeTarge, isDragNodeSource

[mcharfadi]

But should we not set the value to the previous value instead of false.

What would happen if a node has moving true but another user refresh the diagram, that would set moving to false and create an incorrect state, no ?

We might want to do like the selection and retrieve the current one after converting.

As a side note we should find a naming convention or something to differentiate between local attributes of a node and synchronized ones.

[frouene]

In this case, we only want capture the move if it's made by the current user, it's the same thing that for the other data like isDraggedNode, if a refresh from another user is received during DnD the data is reset to false.