Angular 的开发者预览流程让我们能够在 API 和功能投入生产之前为开发者提供试用机会，并让我们能够根据实际使用情况和反馈灵活调整这些 API。 通过开发人员预览期间对 effect() API 的反馈，我们发现了一些设计改进，这些改进将解决功能和开发人员体验方面的实际问题。 因此，我们将对 API 进行有意义的修改，并很高兴与大家分享。

删除 allowSignalWrites

偶尔有必要在 effect() 中设置 signals，但更常见的情况是，这表明 effect 是不适合该工作的工具，而另一种 API（如 computed()）会更合适。 为了鼓励良好的模式，我们最初设计的 effect() API 禁止设置 signals，除非明确设置了 allowSignalWrites 标志。

通过开发人员反馈和观察实际使用情况，我们得出的结论是该标志没有提供足够的价值。我们发现它不能有效地鼓励良好的模式，并且最终在更新 signals 是合理的情况下不鼓励使用 effect() 。

因此，我们决定在 v19 中完全删除 allowedSignalWrites 标志，并默认允许 effect 设置 signals。相反，我们将专注于鼓励良好模式的其他方法，包括在需要时添加新的反应性助手函数。

时机很重要

我们还对 effect 运行的时间进行了重大更改。具体来说，我们正在将 effect 移至更改检测期间作为组件层次结构的一部分运行，而今天它们作为微任务独立排队和调度。

此更改的目标是使 effect 计时更加可预测和有用，解决有关 effect 运行太早或太晚的许多错误，并确保相对于组件树，“父” effect 在“子” effect 之前运行。

这对您的项目有何影响？

一般来说，effect API 的大多数用途将继续按预期工作，但以下是一些需要注意的用例：

• 对 view queries 结果的影响，它依赖于在更改检测后运行以读取 .offsetWidth 等 DOM 属性。新的 afterRenderEffect API 通常是直接替代品。
• signal inputs 的 toObservable() 现在比以前更早发出，这会影响 Observable 链的时序。在某些情况下，我们发现这会产生不必要的额外 RPC。
• 依赖于 effect 内部非 signal view queries 的可用性（signal queries 可以在这里提供帮助，afterRenderEffect 也可以）。
• 与表单的交互 Observables 和值对计时问题特别敏感——延迟创建 effect 或使用 signals 将 effect 延迟到 ngAfterViewInit 或 afterNextRender 会有所帮助。

在 Google 测试此更改时，我们修复了大约 100 个时间更改对代码产生重大影响的情况。其中大约一半是仅测试的更改，在少数情况下，时间差异导致了更正确的应用程序行为。

effect 仍然处于预览状态吗？

是的。由于这些更改，我们决定至少在 v19.0 之前将 effect() 保留在开发者预览版中。假设围绕新行为的反馈是积极的，我们计划在即将到来的次要版本中稳定 API。

反馈是一份礼物

感谢 Angular 社区的所有人，感谢你们在 Angular 的开发中发挥的重要且有影响力的作用。由于您对这个框架的持续支持和热情，我们能够走到这一刻，并且受到许多人的喜欢。

此更改即将落地，您可以在最新的 RC 版本中进行测试，希望您喜欢。