我很想亲自看看这个。实际上这里有几个非常相关的PR:

• Initial implementation of the Tracing Hooks API #25763
• Initial implementation of the Tracing Hooks API #29870

但是Joe对那个的评论有些令人沮丧：
我们之前作为一个团队讨论过这个问题，我们非常担心长期支持这个的成本。虽然意图只是为了非关键性(对应用程序正确性)的事情，比如性能监控，但不可避免的是应用程序或库最终会依赖这些钩子来实现其核心行为。这会让我们放慢速度，因为这会让许多内部重构变成破坏性的更改，延迟这些重构和它们将解锁的改进。
我们认为正确的第一步是我们在实验室帖子中讨论过的过渡跟踪API。在我们的待办事项列表中。

是的，这绝对不是什么应该阻碍React前进的事情。如果事情发生了变化，它们就会发生变化。这只会让问题浮出水面。
这个想法更多的是为了确保，如果发布了一个新的React版本，并且我们的其中一个API意外地开始看到额外的渲染，我们可以更快地捕获并修复它，而不是拖到后面。
这当然只针对一个“测试”用例——这也是我为什么建议像react-dom/test这样的入口点的原因。

你是否探索过将你的测试用例 Package 在 React.Profiler 中，并在渲染回调上进行Assert？I explored that originaly in MUI。这个想法是将每个测试用例都 Package 在 React.Profiler 中，并跟踪更改。它看起来很有前途，但我没有以一种有用的方式完成它(p90,提交之间的差异，随时间变化的测量等)。
如果你想通过不在这些测试中使用 act 来获得更准确的实际世界结果，你可以查看一下。
过渡追踪可以帮助我们获得更详细的见解。尽管如此，也许我们可以只是公开更新器跟踪 React Devtools 已经访问过的("为什么这次渲染了？" 在 Profiler 面板中)。

你是否探索过将测试 Package 在React.Profiler中并在渲染回调上进行Assert？
我们确实这样做了——我们将测试 Package 在React.Profiler中，并且在每个onRender回调中，我们创建DOM的快照以及额外的测试特定值(钩子返回值等)。
我们并没有立即进行Assert，而是将这些值保存到一边，以便在其他时候对它们进行Assert。
如果你想通过不在这些测试中使用act来获得更准确的实际世界结果，你可以尝试一下。
现在我很好奇——不是建议使用act来获得更实际的世界结果吗？
尽管如此，也许我们可以只公开更新器跟踪React Devtools已经访问过的数据。
是的，请让我们从小事做起——完美是“一点也不”的敌人，目前DevTools中有大量的数据是我们无法从测试中直接访问的。获取这些数据本身就已经非常棒了，我们现在不需要更多的东西！

我们确实会这样做 - 我们将测试 Package 在React.Profiler中，并在每个onRender回调中，我们创建DOM的快照以及额外的测试特定值(钩子返回值等)。
我们并不会立即进行Assert，而是将这些值保存到一边，以便在其他时候对它们进行Assert。
所以你实际上不感兴趣于性能分析，而是希望进行更细粒度的Assert。我认为你只是想在中间步骤上进行测试，而不是使用性能分析工具。
现在我很好奇 - 建议使用act来获得更真实的结果吗？
act() 在退出之前刷新所有计划好的内容。这不一定是你在实际应用程序中看到的结果，例如React接收到mousemove事件时，它可能会将状态更新批量提交为单个提交。如果你将两者都 Package 在act中，你总是会得到两个提交。
是的，请开始小步前进 - 完美是“任何事情”的敌人，目前有大量的数据可以供DevTools访问，而我们无法从测试中直接访问这些数据。获得这些数据本身就已经很不可思议了，我们现在不需要更多的东西！
除了这些目前存在漏洞和错误。过渡跟踪仍在进行中，因此我们不应该仅仅暴露更新器跟踪，而是有了一些东西。在React的规模上发布未完成的东西是有代价的。如果它不起作用，需要花费大量工作来移除它，阻碍生态系统的发展。这在内部仓库(如Meta)中有效，因为你有直接访问权限，但无法扩展到具有未知优先级和动机的生态系统。

act() 在退出之前清除了所有计划好的内容。这不一定是你在现实世界应用程序中会看到的东西，例如 React 接收到鼠标移动事件时，它可能会将状态更新批量提交为单个提交。如果你将两者都用 act 包裹，你总是会得到两个提交。

这是 act 上绝对有用的信息，我从未在其他地方看到过这样的沟通——谢谢你提供这个信息。

所以你实际上并不对性能分析感兴趣，而是希望进行更细粒度的Assert。我认为你只是想在不使用 act 的情况下测试，以便在中间步骤上进行Assert，而不是性能分析工具。

我们确实对一些“类似性能分析器”的东西很感兴趣，比如在两次成功渲染之间实际提交了哪些组件，以及渲染完成提交的具体时刻(testing-library 的 waitFor 总是存在“跳过”渲染的风险)。

也许我们不需要一个全新的 API,尽管如此——在给予更多思考后，在 onRender 回调中获取一些额外的信息可能更适合这个功能。

不过目前这些都有漏洞和错误。过渡跟踪仍在进行中，所以我们不应该仅仅暴露 updater 跟踪，而是应该有什么东西。在 React 的规模上发布未完成的东西是有代价的。如果它不起作用，需要大量的工作来移除它，阻碍生态系统的发展。这在内部仓库(如 Meta)中有效，因为你有直接访问权限，但无法扩展到具有未知优先级和动机的生态系统。

从 TypeScript 类型来看，似乎过去某个时候有很多额外的信息(interactions),但又被移除了——也许对于像 Profiler 这样的事情来说，实际上并没有那么糟糕？

当然，我理解如果你们需要更多的时间来稳定这个功能——但如果团队能从长远的Angular 考虑这个功能请求，我会非常高兴。