共计 1116 个字符，预计需要花费 3 分钟才能阅读完成。
背景
入职头条快一年，平时工作中，不止一次听到 UI 反馈，头条 App 内的 h5 上偶然会呈现上面这样的体验 bug。
在缩略符“…”后面会小概率呈现标点符号，看起来很不雅观。这么长时间这个问题始终没解决，因为本人手头的业务有点多也就没去关注这个别人需要。
最近刚好弄完绩效评估处于需要真空期，刚好想起这个问题，就棘手给解决了，积淀了个 react 的缩略组件。思考到这是个很通用的需要，所以整顿了一下开源进去。
<!– more –>
先间接上干货吧，组件曾经开源在 github 上，仓库地址：react-ellipsis (感觉有用能够给个 star)。
可能会有人纳闷，这么常见的需要真的没有可用的轮子吗？我一开始也带着这个纳闷，搜了一下 npm 和 github，发现还真没有能齐全符合条件的 …
那就本人来造一个吧 -。-
造轮子前
在筹备入手解决问题前，我浏览了一下 npm 和 github 上已有的缩略组件，依据 star 数挑几个看看
react-lines-ellipsis
截止发文
- stars 数 376
- 未解决 issue 15
- 上次性能更新 2 年前
问题：
- 不反对结尾标点符号过滤，只能过滤空白符（可通过 pr 解决，然而作者很长时间未解决 pr 了）
- 每个 ellipsis 组件都会生成一个暗藏的 div 去计算，性能损耗重大
- 不反对设置高度缩略
react-truncate
截止发文
- stars 数 503
- 未解决 issue 33
- 上次性能更新 8 月前
问题：
- 不反对结尾标点符号过滤，只能过滤空白符
- 不反对按单词或字母切割
- onResize 须要自行调用
- 应用 canvas 实现，当元素较多时性能损耗重大
其余组件或多或少都有各自的问题导致无奈满足咱们的需要，所以入手本人撸吧。
轮子介绍
吭哧吭哧搞了一个下午就写完了，目前迭代到 0.5.2 版本。
先看个简略的示例，更多示例和应用办法能够查看 react-ellipsis 文档
Q & A
-
如何保障性能？
切割算法上，其余组件大多是通过切割成字符数组后，一个个缩小直到容器不再溢出，工夫复杂度是 O(n)。react-ellipsis-component 应用二分切割将工夫复杂度降到 O(logn)。
计算时在原容器上计算，其余组件应用暗藏的 div 或者 canvas，当 ellipsis 组件很多时性能损耗重大。
在自适应上，应用 ResizeObserver 实现，而其余组件应用 window.onresize（性能损耗比拟大）。
-
兼容性
兼容性次要在于 ResizeObserver 实现的自适应缩略，如果不须要自适应缩略，能够笼罩绝大部分的古代浏览器。组件自身除了 react 不依赖其余库，兼容性有保障。
后续会增加 window.onresize 的兼容逻辑进一步提高兼容性。
附：ResizeObserver 兼容性表