Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

クローズ
  • 何か問題がありますか？
#8,580 コメント 1 件 リアクション 0 件 担当者 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
スター
321
フォーク
192
平均マージ
2日 16時間
マージ済み PR（30日）
136

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

apache/texera のほかの issue

apache/texera の issue をすべて見る

似ている issue

Scala の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。