Angular由一个bug说起之二十一：async pipe 在处理 tooltip 显示逻辑上的运用

前言
在前端 UI 中，是否显示 tooltip 通常依赖文本是否被截断（是否展示省略号）。这个判断看似简单，但在真实场景中需要通过 DOM 测量（例如元素宽度、字体测量）来决定，且这些测量必须在元素渲染后才能得到正确值。来讲解 async pipe 的常见用法与优势，说明它如何简化基于 DOM 的“是否启用 tooltip”逻辑。

---

一、async pipe 的习惯用法

• async pipe 可以在模板中直接解包（unwrap）Promise 或 Observable 的值，例如：

1. Promise: {{ myPromise | async }}
2. Observable: {{ myObservable$ | async }}

• 优点：

1. 自动订阅（Observable）并在组件销毁时自动退订，避免内存泄漏。
2. 有序列表当 Promise/Observable 解析或发出新值时，会触发 Angular 的变更检测去更新模板。
3. 模板级别把“异步结果消费”变得非常简洁，无需组件层的显式 subscribe/then/手动管理。

---

二、disabledTooltip.pipe.ts 的使用场景（代码摘录并解释）

<div [tooltip]="textToDisplay"
     [isDisabled]="textToDisplay | disabledTooltip | async">
    {{ textToDisplay }}
</div>

transform(inputText: string, lineLimit?: number): Promise<boolean> {
    return new Promise((resolve) => {
        setTimeout(() => {
            const isEmpty = !inputText || inputText.trim().length === 0;
            let shouldDisable = isEmpty;
            
            if (!isEmpty) {
                const mockElementWidth = 150;
                const mockFontStyle = "14px sans-serif";
                
                if (lineLimit && lineLimit > 1) {
                    const truncatedText = this.mockTextTruncation(inputText, mockFontStyle, lineLimit, mockElementWidth);
                    shouldDisable = truncatedText === inputText;
                } else {
                    const calculatedWidth = this.mockWidthCalculation(inputText, mockFontStyle);
                    shouldDisable = calculatedWidth <= mockElementWidth;
                }
            }
            resolve(shouldDisable);
        });
    });
}

// Mock 文本截断方法
private mockTextTruncation(text: string, font: string, lines: number, width: number): string {
    // 模拟多行文本截断逻辑
    const maxCharsPerLine = Math.floor(width / 8);
    const maxTotalChars = maxCharsPerLine * lines;
    
    if (text.length <= maxTotalChars) {
        return text;
    }
    return text.substring(0, maxTotalChars - 3) + '...';
}

// Mock 宽度计算方法
private mockWidthCalculation(text: string, font: string): number {
    // 模拟文本宽度计算 - 基于字符数和字体大小
    const baseCharWidth = 8;
    return text.length * baseCharWidth;
}

关键点：

  - 这条 pipe 返回的是 Promise，因此模板需要配合 async pipe 使用来展开值。
  - 判断逻辑：
    1. 如果文本为空 => 禁用 tooltip（disabled = true）。
    2. 否则取元素宽度和字体信息，通过两种方式判断是否超出：
      - 单行（或未指定多行）：用 canvas 测量文本宽度并与元素宽度比较。
      - 多行（maxLines>1）：调用 mockTextTruncation来模拟按行显示和省略号行为，再与原文本比较决定是否被截断。
   - setTimeout 被用于把逻辑延迟到下一轮事件循环，确保元素已渲染，mockWidthCalculation能拿到正确尺寸。

---

三、tooltip 显示条件判断遇到的难题

1. 有序列表DOM 必须已渲染才能正确测量
      - 在 Angular 的生命周期中，如果在视图尚未渲染时测量元素宽度，会得到错误或 0。
2. 需要在变化后更新判断（例如文本变了、容器宽度变了、字体样式变了）
      - 有序列表文本或容器尺寸变化后要重新计算是否需要 tooltip。
3. 如果希望在组件层处理，需要大量模板与组件之间的协作，常见实现较为繁琐：
      - 在组件里监听宽度变化（window resize / ResizeObserver）
      - 在组件里订阅文本变化并在 AfterViewChecked / setTimeout 中测量
      - 手动管理订阅和变更检测（可能导致内存泄漏或过度刷新的问题）
4. race condition 与性能问题
      - 文本短时间内频繁改变会导致大量测量；若每次都在组件中手动 subscribe/then，会产生抖动或不必要计算。
5. 视图更新与变更检测
      - 测量完成后需要确保模板能感知到 Promise/Observable 的结果并更新 DOM（需要触发变更检测）。
6. 代码重复与职责不清
      - 如果每个需要 tooltip 的组件都实现测量逻辑，会产生大量重复代码，难以维护。

---

四、过去的解决方法与局限

transform(inputText: string): boolean {
    if (!inputText || inputText.trim().length === 0) {
        return true;
    } else {
        const element = this.elementRef.nativeElement;
        const offsetWidth = element.offsetWidth;
        const offsetWidth = 200;
        const calculatedTextWidth = this.mockTextWidthCalculation(inputText, "14px Arial");
        const shouldEnable = calculatedTextWidth > offsetWidth ;
        return !shouldEnable;
    }
}

private mockTextWidthCalculation(text: string, fontStyle: string): number {
    const baseCharWidth = 8;
    let widthMultiplier = 1;
    
    if (fontStyle.includes('16px')) widthMultiplier = 1.2;
    if (fontStyle.includes('12px')) widthMultiplier = 0.8;
    
    return text.length * baseCharWidth * widthMultiplier;
}

• 解决方法：
     1. 使用 Angular Pipe 来封装判断逻辑
     2. 通过 elementRef.nativeElement 直接获取 DOM 元素
     3. 利用 offsetWidth 获取容器宽度
     4. 使用 mockTextWidthCalculation 服务计算文本宽度
     5. 通过比较文本宽度和容器宽度来决定是否显示 tooltip

• 主要局限性：
     1. 时序问题
       - 直接获取 offsetWidth 在 DOM 未完全渲染时执行，得到错误的 0 值
       - 在字体未加载完成时计算不准确
     2. 无法响应变化
       - 不响应窗口大小改变
       - 不响应容器宽度动态变化
       - 不响应字体大小或样式变化
     3. 功能限制
       - 只支持单行文本判断
       - 不支持多行文本截断检测
       - 返回同步布尔值，无法处理异步状态

---

五、async pipe 如何解决这些问题

1. 把异步决策放到 pipe 层并返回 Promise/Observable
      - transform(…): Promise 允许在 pipe 内做异步计算（例如 setTimeout 延迟）后再返回结果。
2. 模板仅需写一行：[isDisabled]=“text | disabledTooltip | async”
      - 模板清晰，没有组件层的订阅/状态管理。
3. async pipe 自动触发变更检测
      - Promise resolve 或 Observable 发出新值时，async pipe 会自动触发 Angular 的变更检测以更新绑定。
4. 自动管理订阅（Observable）/无需手动 then（Promise）
      - 避免了手动退订或内存泄漏风险（对于 Observable）。
5. 每次输入变化时 pipe 会被调用并返回新的 Promise，从而 async pipe 能拿到最新的异步结果
      - 比如文本变化或组件重新渲染时，会再次触发 transform。
6. 代码职责更清晰
      - 展示判断的实现封装在 pipe 中，组件/模板只消费最终布尔值，减少重复代码。

因此，结合 async pipe，开发者可以把“isDisabled tooltip”这一依赖 DOM 的异步决策放到统一的 pipe 中，模板层非常简洁，组件不再关心测量细节。

---

总结
async pipe 是把异步运算（Promise/Observable）与模板绑定的强力工具，它自动处理订阅和变更检测，使模板代码更简洁、职责更单一。在案例中，async pipe 用来等待基于 DOM 测量后的布尔决策，恰当地解决了“需要等待渲染再测量”的问题，同时避免了组件层的订阅与管理负担。