fix(Typography): fast and efficient syncEllipsis

[nined9]

这个变动的性质是

• 新特性提交
• 日常 bug 修复
• 站点、文档改进
• 组件样式改进
• TypeScript 定义更新
• 重构
• 代码风格优化
• 分支合并
• 其他改动（是关于什么的改动？）

需求背景

1. 描述相关需求的来源。
   切换tab时，typography内容有超出的节点会闪烁原文再显示省略

• typography组件包了一层ResizeObserver(内部)组件，这个组件使用了ResizeObserver(web)接口监听dom元素的resize改变的事件，当触发resize事件后，会调用dom元素的getBoundingClientRect方法获取dom元素的宽高，当宽高和之前不一致时会触发typography的文本重新计算事件。

• 而ResizeObserver(web)接口在dom元素脱离文档流时（比如自己或祖先节点设置display为none了）也会触发，此时dom元素的getBoundingClientRect返回的宽高皆为0，此时仍会触发typography的文本重新计算事件，而当被重新添加时，又会走一遍这个流程，所以在脱离文档流时的那一次计算，其实是多余的。

• 而上面说的闪烁的原因就在这一次多余的计算里产生的，在脱离文档流后执行重新计算时，因为用到了window.getComputedStyle去获取当前dom元素的样式属性，而当前dom元素已经脱离文档流了，所以相关的样式属性和实际是有偏离的，比如width属性，在dom元素处于文档流中时，它是有一个实际的值的，而脱离文档流之后dom元素的width属性在没有特别设置的情况下，就是默认值auto

• 在width是auto时，按ellipsis的计算逻辑，被计算的文本相当于没有宽度的限制，最终的高度只有一行，因此在inRange的判定下，得到的结果都是没有超出，不需要省略，于是就变成了原文展示。
  所以当dom元素被重新添加到文档流后，就会先显示上一次的原文，然后等待ResizeObserver(web)接口的监听事件，再在nextFrame重新去执行typography的文本计算事件。这个过程的耗时显然达到了肉眼可感受到的程度，才导致了节点的闪烁

2. 要解决的问题。
   二次切换到某tab时，该tab下的typography内容有超出的节点会闪烁原文再显示省略

3. 相关的 issue 讨论链接。
   #7145

实现方案和 API

在挂载后，马上进行ellipsis的计算，而不是等nextTick后的nextFrame

对于宽/高为0的Resize事件，直接跳过ellipsis的计算逻辑，避免原文的闪烁

对用户的影响和可能的风险

无

请求合并前的自查清单

• 文档已补充或无须补充
• 代码演示已提供或无须提供
• TypeScript 定义已补充或无须补充
• Changelog 已提供或无须提供

后续计划

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.