Task Summary
Switching between a workflow's two views -- the operator canvas (/user/workflow/:id) and the Form View (/user/workflow/:id/form) -- is a full browser page load in both directions (window.location.href in MenuComponent.openFormViewPage and WorkflowFormComponent.openCanvasPage). The two views are views of one open workflow, so everything that makes the workflow live is thrown away on the way out and rebuilt on the other side:
- both
ngOnDestroys call clearWorkflow() (which destroys the Yjs shared document and leaves its co-editing room), computingUnitStatusService.disconnect(), resetExecutionAndWorkers(), and clear the console and results;
- the arriving view then re-bootstraps Angular (
APP_INITIALIZER blocks on /api/config), re-parses the whole bundle, re-fetches operator metadata that a providedIn: "root" singleton had already cached for the page, fetches the workflow, opens a new shared document and room, reconnects the computing unit, and waits for the backend to report the execution state again.
The visible cost is seconds of blank page on every switch, and a run that was already going takes that long to say so again. Nothing about it is necessary: WorkflowWebsocketService, ComputingUnitStatusService, WorkflowActionService and the joint graph it owns are all root-provided and survive a route change.
Routing between the two was tried during the Form View work and reverted; the code comments record three symptoms, two of which have identified causes:
- A ghost coeditor of yourself. The arriving view built a second shared document for the same workflow, so the page joined the room it was already in and saw its own other client.
- Undraggable operators. A JointJS paper binds to the joint graph, which is root-provided and outlives the component that created it, and no paper is ever disposed -- neither
WorkflowEditorComponent's nor MiniMapComponent's. Every mount left another paper listening to that graph from a detached DOM node, and whichever paper answered a pointer event decided whether an operator could be dragged. Harmless while every mount followed a page load.
- Broken runs. No independent cause found; likely a consequence of the first two, but this is the part that most needs checking in a browser.
Proposed: route in both directions, have the departing view hand the session to the arriving one instead of tearing it down, have the arriving view attach to what it was given instead of rebuilding it, and dispose both papers on destroy. Leaving the workspace altogether keeps today's teardown, including on unload.
Follow-up to the Form View feature (parent issue #8011); the switch itself landed in #8456.
Task Type
Task Summary
Switching between a workflow's two views -- the operator canvas (
/user/workflow/:id) and the Form View (/user/workflow/:id/form) -- is a full browser page load in both directions (window.location.hrefinMenuComponent.openFormViewPageandWorkflowFormComponent.openCanvasPage). The two views are views of one open workflow, so everything that makes the workflow live is thrown away on the way out and rebuilt on the other side:ngOnDestroys callclearWorkflow()(which destroys the Yjs shared document and leaves its co-editing room),computingUnitStatusService.disconnect(),resetExecutionAndWorkers(), and clear the console and results;APP_INITIALIZERblocks on/api/config), re-parses the whole bundle, re-fetches operator metadata that aprovidedIn: "root"singleton had already cached for the page, fetches the workflow, opens a new shared document and room, reconnects the computing unit, and waits for the backend to report the execution state again.The visible cost is seconds of blank page on every switch, and a run that was already going takes that long to say so again. Nothing about it is necessary:
WorkflowWebsocketService,ComputingUnitStatusService,WorkflowActionServiceand the joint graph it owns are all root-provided and survive a route change.Routing between the two was tried during the Form View work and reverted; the code comments record three symptoms, two of which have identified causes:
WorkflowEditorComponent's norMiniMapComponent's. Every mount left another paper listening to that graph from a detached DOM node, and whichever paper answered a pointer event decided whether an operator could be dragged. Harmless while every mount followed a page load.Proposed: route in both directions, have the departing view hand the session to the arriving one instead of tearing it down, have the arriving view attach to what it was given instead of rebuilding it, and dispose both papers on destroy. Leaving the workspace altogether keeps today's teardown, including on unload.
Follow-up to the Form View feature (parent issue #8011); the switch itself landed in #8456.
Task Type