yangzhang75 commented on code in PR #8441:
URL: https://github.com/apache/texera/pull/8441#discussion_r3945970108
##########
frontend/src/app/workspace/component/workflow-form/workflow-form.component.ts:
##########
@@ -161,8 +228,95 @@ export class WorkflowFormComponent implements OnInit,
OnDestroy {
return;
}
this.wid = wid;
+ // Give the result tables a realistic height to page against, so they show
a screenful of rows
+ // instead of one. (~7 rows; the card scrolls for the rest.)
+ this.panelResizeService.changePanelSize(900, 560);
this.load(wid);
+ // A result changing bumps that operator's version (so its chart frame is
rebuilt, not reused),
+ // re-limits what the form shows to the currently-viewed set, and re-fits
the visualisations.
+ this.workflowResultService
+ .getResultUpdateStream()
+ .pipe(untilDestroyed(this))
+ .subscribe(update => {
+ for (const operatorID of Object.keys(update ?? {})) {
+ this.resultVersion.set(operatorID,
(this.resultVersion.get(operatorID) ?? 0) + 1);
+ }
Review Comment:
Verified your point is real: VisualizationFrameContentComponent does
self-update (getResultUpdateStream + auditTime 2s), so bumping the key every
emission destroys that in-place update. I am NOT fixing it blind here: the
correct fix (bump only on a genuinely new result) also has to handle re-runs --
clearResults fires on a separate stream (resultClearedStream), not the
result-update stream -- without reintroducing the stale/undefined-picture bug
this key was added to fix, and the iframe cannot be exercised in jsdom. Tracked
in #8439 to fix and verify on the running instance. Leaving this thread open
until then.
##########
frontend/src/app/workspace/component/workflow-form/workflow-form.component.html:
##########
@@ -141,5 +221,70 @@
class="box"></texera-mini-map>
</div>
</section>
+
+ <!-- Results, under the workflow that produced them. The section keeps its
place before a run so
+ the answer has a visible destination. -->
+ <section class="results">
+ <div class="pc-section-head"><span class="label">Results</span></div>
+ <p
+ class="results-empty"
+ *ngIf="resultIdsToShow.length === 0">
+ {{ isRunning ? "Working…" : "Press Run and the results appear here." }}
+ </p>
+ <!-- A card only for a chosen step that actually produced a result.
Whether a Python UDF
+ yields one cannot be told from the graph, so a step earns its card
at runtime rather than
+ sitting on a permanent "No result yet." (a download/publish step
never would). -->
+ <ng-container *ngFor="let id of resultIdsToShow">
+ <div class="card result">
+ <div class="result-head">
+ <span>{{ resultLabel(id) }}</span>
+ <!-- Zooming only means something once there is a picture to zoom.
-->
+ <span
+ class="result-zoom"
+ *ngIf="vizHasContent(id)">
+ <button
+ (click)="zoomResult(id, -1)"
+ [disabled]="resultZoom(id) <= 0"
+ nz-tooltip="Smaller">
+ <i
+ nz-icon
+ nzType="minus"></i>
+ </button>
+ <button
+ (click)="zoomResult(id, 1)"
+ [disabled]="resultZoom(id) >= 2"
+ nz-tooltip="Bigger">
+ <i
+ nz-icon
+ nzType="plus"></i>
+ </button>
+ </span>
+ </div>
+ <!-- Three cases, in order: a table (it shows its own "Empty result
set" when it has no
+ rows), a visualisation that actually drew something, or nothing
yet -- which
+ collapses to a compact line instead of a tall blank canvas. -->
+ <div
+ class="result-body"
+ [attr.data-zoom]="resultZoom(id)"
+ [ngSwitch]="true">
+ <texera-result-table-frame
+ *ngSwitchCase="isTabularResult(id)"
+ [operatorId]="id"></texera-result-table-frame>
+ <ng-container *ngSwitchCase="vizHasContent(id)">
+ <!-- Keyed on the result's version so a new result builds a new
frame: the component
+ reads its content once, at creation. -->
+ <texera-visualization-panel-content
+ *ngFor="let key of [resultKey(id)]; trackBy: trackByKey"
+ [operatorId]="id"></texera-visualization-panel-content>
Review Comment:
Same as the ts:244 thread: real inefficiency (the viz self-updates via
auditTime), deferred to #8439 to fix and verify on a flag-on instance rather
than risk the stale-picture regression. Left open until done.
--
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]
