yangzhang75 commented on code in PR #8839:
URL: https://github.com/apache/texera/pull/8839#discussion_r4309333174
##########
frontend/src/app/workspace/component/hugging-face/hugging-face.component.ts:
##########
@@ -517,10 +563,15 @@ export class HuggingFaceComponent extends
FieldType<FieldTypeConfig> implements
}
clearSearch(): void {
+ this.resetSearch();
+ this.goToPage(0);
+ }
+
+ /** Forget the search: the text, the results it filtered to, and the spinner
it was waiting on. */
+ private resetSearch(): void {
this.searchText = "";
this.filteredModels = null;
this.searchLoading = false;
Review Comment:
Confirmed and fixed. `resetSearch()` now drops the search subscription and
remakes it, which discards both a query still sitting in the debounce and a
request already out; nothing queued can go back out under the task the widget
has moved to.
That makes the tag the answer travelled with unreachable, so it is gone:
whatever reaches the subscriber was asked for under the task still shown
(switchMap drops a search the next search replaces, a task change drops the
whole subscription). The comment there says so, in place of the guard.
Tests: a query typed and overtaken by a task change never goes out and
leaves the box empty and unfiltered; a search after a task change still goes
out, under the new task. The two late-response tests now expect cancellation
rather than a judged answer, as you suggested. Both halves deletion-checked.
##########
frontend/src/app/workspace/component/workflow-form/workflow-form.component.ts:
##########
@@ -543,6 +543,23 @@ export class WorkflowFormComponent implements OnInit,
OnDestroy {
*/
@HostListener("focusout")
public onFocusOut(): void {
+ this.flushHeldRebuild();
+ }
+
+ /**
+ * A click or a key inside the page also ends a hold, because a focus change
is not the only thing
+ * that does: closing an nz-select leaves the focus in its search box
(ng-zorro re-focuses it), so
+ * no focusout fires, and a rebuild held while the list was open would have
waited for an unrelated
+ * event (Copilot on #8839). The same later() re-check as below decides it
after the current tick,
+ * by when the dropdown has lost its open class.
+ */
+ @HostListener("click")
+ @HostListener("keyup")
+ public onInteraction(): void {
+ this.flushHeldRebuild();
Review Comment:
Checked against the rebased branch and this one is already closed, by #8845
which landed on main in the meantime: `buildForm()` writes every card's pending
edit before it emits `formsRebuilt` (`this.rendered.forEach(card =>
card.pendingWrite && card.flushWrite?.())`), so the held rebuild flushes the
selection instead of cancelling it.
Added the regression test you asked for anyway, since nothing pinned this
path from the keyup side: a rebuild held while the list is open, an option
accepted, then the click that closed the list runs the rebuild -- the selection
reaches the operator. Deletion-checked by removing the flush, which turns it
red.
--
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]
