Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Switching between a workflow's canvas and Form View reloads the page and reconnects everything

已关闭
  • 哪里不对？
#8,580 1 条评论 0 个 reaction 已指派 1 人 在 GitHub 查看

维护者通常 1 天内回复

@yangzhang75 已经在做这个了。

开始于 2026年9月19日。

评估

这个 Issue 还没有评估数据。

描述

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:

  1. 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.
  2. 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.
  3. 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
  • Performance
  • Refactor / Cleanup
主要语言
Scala
星标
322
派生
195
平均合并
2 天 16 小时
30 天内合并 PR
127

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

apache/texera 的其他 Issue

查看 apache/texera 的全部 Issue

相似的 Issue

更多 Scala Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。