@flywheel-io/vision 21.1.2 → 21.1.3

package/fesm2022/flywheel-io-vision.mjs

@@ -3177,10 +3177,26 @@ class FwDialogComponent {
         return classes;
     }
     ngOnInit() {
-        this.dialogRef?.containerInstance?._addAriaLabelledBy(this.headerId);
+        // `<fw-dialog>` is usable outside an overlay, so there may be no dialogRef at all.
+        const container = this.dialogRef?.containerInstance;
+        if (container) {
+            // Deferred by one microtask on purpose: `_addAriaLabelledBy` mutates the container's
+            // `_ariaLabelledByQueue`, which `CdkDialogContainer` exposes as a host binding. A component's
+            // host bindings are evaluated in its parent view *before* Angular descends into child
+            // components, so mutating the queue synchronously here changes a value the container already
+            // read in the same change-detection pass, which throws NG0100 in dev builds. Same approach as
+            // Angular Material's `MatDialogLayoutSection`.
+            Promise.resolve().then(() => container._addAriaLabelledBy(this.headerId));
+        }
     }
     ngOnDestroy() {
-        this.dialogRef?.containerInstance?._removeAriaLabelledBy(this.headerId);
+        const container = this.dialogRef?.containerInstance;
+        if (container) {
+            // Deferred to stay ordered behind the deferred add in `ngOnInit` — otherwise a dialog created
+            // and destroyed within the same task would remove the id before it was ever added and leave
+            // it orphaned in the queue.
+            Promise.resolve().then(() => container._removeAriaLabelledBy(this.headerId));
+        }
     }
     handleCloseButton() {
         this.closeWithAnimation();
@@ -4324,6 +4340,16 @@ class FwMenuItemComponent {
         this.focused = model(false, ...(ngDevMode ? [{ debugName: "focused" }] : /* istanbul ignore next */ []));
         this.selected = model(false, ...(ngDevMode ? [{ debugName: "selected" }] : /* istanbul ignore next */ []));
         this.subscriptions = [];
+        this.isDestroyed = false;
+    }
+    /**
+     * Whether this item's view has been torn down. Owners that iterate their items (`fw-menu`) have to
+     * check this before writing to the item's `model()`s: neither `QueryList` nor a signal query is
+     * emptied by view destruction, so an item can still be reachable from a query after the menu it
+     * lives in was destroyed - writing to it then logs NG0953.
+     */
+    get destroyed() {
+        return this.isDestroyed;
     }
     scrollIntoView(options = { behavior: 'smooth', block: 'nearest' }) {
         // eslint-disable-next-line @rx-angular/prefer-no-layout-sensitive-apis
@@ -4341,6 +4367,7 @@ class FwMenuItemComponent {
         this.updateLayout();
     }
     ngOnDestroy() {
+        this.isDestroyed = true;
         for (const subscription of this.subscriptions) {
             subscription.unsubscribe();
         }
@@ -4487,9 +4514,15 @@ class FwMenuComponent {
     }
     writeValue(value) {
         this.value.set(value);
+        // Lay the items out BEFORE calling out to any listener. `change` is wired to `fw-select`'s
+        // `handleClick`, which closes the options panel and so synchronously destroys every
+        // `fw-menu-item` rendered in it. View teardown does not empty a `QueryList`, so laying out
+        // afterwards writes to `model()`s on already-destroyed nodes, which logs NG0953 once per item
+        // whose `selected` flag changed. Everything `updateLayout()` reads derives from `this.value()`,
+        // set on the line above, so the resulting layout is identical either way.
+        this.updateLayout();
         this.onChange(value);
         this.change.emit(value);
-        this.updateLayout();
     }
     registerOnChange(fn) {
         this.onChange = fn;
@@ -4528,6 +4561,12 @@ class FwMenuComponent {
         if (this.menuItems) {
             const itemRole = this.computeItemRole();
             this.menuItems.forEach((item) => {
+                // A destroyed item is still reachable through the QueryList; writing to its models would
+                // emit on a dead OutputRef (NG0953). Belt and braces for any other listener that tears the
+                // menu down from underneath a layout pass.
+                if (item.destroyed) {
+                    return;
+                }
                 item.itemRole.set(itemRole);
                 const size = this.size();
                 if (size !== undefined) {
@@ -6361,7 +6400,9 @@ class FwSelectMenuComponent {
                 return displayFn(selectedMenuItem);
             }
             const selectedOption = options.find((opt) => opt[this.valueProperty()]?.toString() === currentValue);
-            return selectedOption?.[this.titleProperty()] || '';
+            // `||` would swallow a legitimate `0` title and leave the input showing its placeholder, and it
+            // would also let a non-string title through into this `linkedSignal<string>` untouched
+            return String(selectedOption?.[this.titleProperty()] ?? '');
         }, ...(ngDevMode ? [{ debugName: "selectTitle" }] : /* istanbul ignore next */ []));
         // Watch for menu items changes and re-subscribe
         this.menuItemsWatcher = effect(() => {
@@ -8526,8 +8567,12 @@ class FwStepperComponent {
             return;
         }
         this.activeStep.set(step);
-        this.stepChange.emit(parseInt(step?.toString())); // weirdly passing out step directly fails the eqeqeq
+        // Same ordering rule as FwMenuComponent.writeValue: lay the steps out before calling out to a
+        // listener, so a handler that removes the stepper cannot leave `updateSteps()` writing to
+        // `model()`s on destroyed `fw-step`s (NG0953). `updateSteps()` only reads `activeStep()`, set
+        // on the line above, so the layout is unchanged.
         this.updateSteps();
+        this.stepChange.emit(parseInt(step?.toString())); // weirdly passing out step directly fails the eqeqeq
     }
     updateSteps() {
         if (this.steps && this.steps.length > 0) {