TanStack 推出了 Table v9 的 beta 版本，这是一个数据网格库，允许开发者仅按需选择所需的功能。打包体积缩小至约 5 KB，并且消除了曾让排序或过滤操作感觉滞后的交互到下次绘制 (INP) 延迟。

为什么这次变更至关重要

在 v8 版本中，无论项目是否使用，库都会提供所有的网格逻辑——排序、过滤、分页、行选择、分组。这些额外的代码会在主线程上运行，增加打包体积并导致用户操作延迟。对于需要快速响应表格的仪表板而言，几毫秒的延迟就可能使 INP 分数降至较低范围。

v9 的不同之处

  • 按需引入功能模块 – 仅导入你实际使用的部分。如果你跳过了排序功能，排序代码就永远不会进入打包文件中。
  • 集成 TanStack Store – 使用细粒度的 store 来管理状态，这样更新单行时就不会触发过滤器栏或其他无关 UI 的完整重新渲染。
  • 降低内存占用 – 在长时间会话期间，更少的对象和数组可以减轻 JavaScript 堆内存的压力。

这些变化意味着更小的下载体积（对于简单的列表，库的大小可以接近 5 KB），并且在网格繁忙时提供更流畅的交互。

谁将从中受益

  • 前端团队 – 构建内部工具、管理面板或以表格为主要 UI 元素的 SaaS 仪表板。
  • 关注性能的网站 – 监控 Core Web Vitals 的网站；较低的 INP 会直接改善该指标。

v9 无法解决的问题

这些改进针对的是你可以控制的代码。它们不会神奇地加速加载海量 JSON 负载的页面，也不会抵消重量级第三方脚本带来的开销。大数据集仍然需要合理的分页，网络延迟仍是一个独立的问题。

实际的迁移路径

  1. 识别最沉重的表格 – 寻找那些已经出现明显延迟的订单列表、库存网格或 CRM 视图。
  2. 获取基准指标 – 在进行任何更改之前，记录这些页面上的 INP 和长任务 (long-task) 时长。
  3. 逐个迁移网格 – 将 v8 的导入替换为 v9 的模块集，仅启用屏幕实际使用的功能。
  4. 避免使用全量 stockFeatures 包 – 引入默认的功能集会违背减小体积的初衷。
  5. 重新测试交互 – 再次测量排序、过滤和选择操作，以确认性能提升。

反方观点：并非万灵药

一些开发者可能会期望 v9 能解决所有的 UI 迟钝问题。实际上，库带来的收益受限于你可以精简的自定义代码量。如果表格的瓶颈在于行数过多或服务器 API 效率低下，那么减小打包体积带来的影响将非常有限。

后续关注点

核心要点： TanStack Table v9 为你提供了一种切实可行的方法，让你不再为未使用的网格功能买单。通过仅导入所需的模块并使用细粒度的 store，你可以减少几 KB 的打包体积，并提供明显更敏捷的表格交互——前提是你要将升级与合理的数据处理策略结合起来。