rfellows commented on code in PR #11773:
URL: https://github.com/apache/nifi/pull/11773#discussion_r4208913210
##########
nifi-frontend/src/main/frontend/apps/nifi/src/app/ui/common/canvas/canvas.component.ts:
##########
@@ -566,7 +691,19 @@ export class CanvasComponent implements OnInit,
AfterViewInit, OnDestroy {
if (connectionsChanged) {
// Connections changed (added/removed) - create new array
+ const previous = this._internalConnections;
this._internalConnections = this.mapConnections(inputConnections);
+ for (const connection of this._internalConnections) {
+ const existing = previous.find((item) => item.entity.id ===
connection.entity.id);
+ if (!existing) continue;
+ connection.ui.dragStartEntity = existing.ui.dragStartEntity;
+ connection.ui.dragStartRevision =
existing.ui.dragStartRevision;
+ connection.ui.dragStartBends = existing.ui.dragStartBends;
+ connection.ui.dragging = existing.ui.dragging;
+ connection.ui.bends = existing.ui.bends;
Review Comment:
In preparation for editable troubleshooting mode, could reconciliation
distinguish in-flight state from idle state and refresh `ui.bends` from the
latest entity when idle? Preserving these bends is important during an active
gesture or pending save, but the same-ID update path otherwise replaces only
`existingConnection.entity`, while the renderer initializes `ui.bends` only
when it is absent. Once populated, externally updated bend geometry can
therefore remain visually stale. A regression test could update the bends while
retaining the same connection ID.
##########
nifi-frontend/src/main/frontend/apps/nifi/src/app/ui/common/canvas/layers/connection-layer/connection-renderer.ts:
##########
@@ -436,10 +501,194 @@ export class ConnectionRenderer {
});
}
+ private static attachEndpointReconnect(
+ endpoints: d3.Selection<SVGRectElement, Position, SVGGElement,
CanvasConnection>,
+ connection: CanvasConnection,
+ context: ConnectionRenderContext
+ ): void {
+ const drag = d3
+ .drag<SVGRectElement, Position, { element: SVGRectElement }>()
+ .subject(function () {
+ return { element: this };
+ })
+ .filter(
+ () =>
+ context.getCanEdit() &&
+ context.getCanSelect() &&
+ !!context.getReconnect() &&
+
!context.getDisabledConnectionIds().has(connection.entity.id)
+ )
+ .on('start', (event) => {
+ event.sourceEvent.stopPropagation();
+ connection.ui.endPointDragging = true;
+ connection.ui.dragging = true;
+ connection.ui.dragStartRevision = connection.entity.revision;
+ })
+ .on('drag', (event, point) => {
+ event.sourceEvent.stopPropagation();
+ const reconnect = context.getReconnect();
+ const root = context.canvasRootResolver();
+ const group = d3.select<SVGGElement,
CanvasConnection>(event.subject.element.parentNode as SVGGElement);
+ if (!reconnect) {
+ ConnectionRenderer.cancelEndpointReconnect(group, root,
context.processGroupId);
+ return;
+ }
Review Comment:
In preparation for the forthcoming editable troubleshooting mode, could we
offset the dragged endpoint handle away from the pointer? The handle has
`pointer-events: all` and is currently centered directly beneath the pointer,
which can cause it to win browser hit-testing over an underlying destination
component and prevent that component from acquiring `g.hover`. An offset such
as `event.x - 8` / `event.y - 8`, or disabling pointer events on the handle
during the gesture, would avoid that interference. A browser-level pointer test
would also be useful because the current tests apply the hover class directly.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
