Reaction v17.0

今天，我们将发布Reaction 17！我们已经在REACTION 17RC博客文章中详细介绍了REACTION 17版本的作用和它所包含的更改。这篇文章是对它的简要总结，所以如果你已经读过RC文章，你可以跳过这篇文章。

REACTION 17版本不同寻常，因为它没有添加任何面向开发人员的新功能。相反，此版本主要侧重于简化Reaction本身的升级。

具体地说，Reaction 17是使将由一个版本Reaction管理的树嵌入由不同版本的React管理的树内变得更安全的“垫脚石”版本。

Reaction 17支持逐步的Reaction升级。当你从RECTION 15升级到16(或者，这一次是从REACTION 16升级到17)时，你通常会一次升级整个应用程序。这对许多应用程序都很有效。但是，如果代码库是在几年前编写的，并且没有积极维护，那么它可能会变得越来越有挑战性。虽然可以在页面上使用两个版本的Reaction，但在Reaction 17之前，这是脆弱的，并且会导致事件问题。

我们正在用Reaction 17解决其中的许多问题，这意味着当Reaction 18和下一个未来版本发布时，你现在将有更多的选择。第一个选择是一次性升级你的整个应用程序，就像你以前可能做的那样。但您也可以选择逐个升级您的应用程序。例如，您可能决定将应用程序的大部分迁移到REACTION 18，但在REACTION 17上保留一些延迟加载的对话框或子路由。

这并不意味着你必须逐步升级。对于大多数应用程序来说，一次性升级仍然是最好的解决方案。加载两个版本的Reaction-即使其中一个是按需延迟加载的-仍然不理想。然而，对于没有积极维护的大型应用程序，考虑这个选项是有意义的，并且REPACTION 17让这些应用程序不会被抛在后面。

我们已经准备了一个示例存储库，演示如何在必要时延迟加载较旧版本的Reaction。本演示使用create Reaction App，但是应该可以使用任何其他工具遵循类似的方法。我们欢迎使用其他工具作为拉式请求的演示。

我们已经将其他更改推迟到Reaction 17之后。此版本的目标是实现逐步升级。如果升级到Reaction 17太难了，那就违背了它的目的。

要启用渐进式更新，我们需要对Reaction事件系统进行一些更改。Reaction 17是一个主要版本，因为这些更改可能会造成破坏。您可以查看我们的版本控制常见问题解答，了解更多关于我们对稳定性的承诺。

在REACTION 17中，REACT将不再在幕后附加文档级的事件处理程序。相反，它会将它们附加到呈现反应树的根DOM容器中：

在REACTION 16和更早版本中，REACTION将对大多数事件执行Document.addEventListener()。REACTION 17将在幕后调用rootNode.addEventListener()。

我们已经确认，多年来在我们的问题跟踪器上报告的大量与集成Reaction和非Reaction代码相关的问题已经通过新的行为得到了修复。

如果您在此更改中遇到问题，这里有一个解决问题的常用方法。

REACTION 17RC的博客文章描述了REACTION 17中的其余突破性变化。

我们只需要更改Facebook产品代码中10万+个组件中的不到20个组件就可以处理这些更改，所以我们预计大多数应用程序都可以毫不费力地升级到17个。如果你遇到问题，请告诉我们。

REACTION 17支持新的JSX转换。我们还支持它响应16.14.0、响应15.7.0和0.14.10。请注意，它完全是选择加入的，您不必使用它。经典的JSX转换将继续工作，并且没有停止支持它的计划。

Reaction Native有一个单独的发布时间表。我们目前预计对REACTION 17的支持将在REACTION Native 0.65中落地，但具体版本可能会发生变化。一如既往，您可以在Reaction Native Community发布问题跟踪器上跟踪发布讨论。

停止公开Reaction Native Web不需要的内部内容。(@#18483中的Necolas)。

在DEV模式双渲染的第二个渲染过程中禁用控制台。(#18547中的@sebmarkpage)。

禁用<；div隐藏/>；预渲染以支持不同的未来API。(#18917中的@acdlite)。

修复导致挂起树中的更新丢失的错误。(#18384和#18457中的@acdlite)。

修复可能导致更新丢失的输入错误。(#18515中的@jddxf和#18535中的@acdlite)。

如果要补水，不要剪掉悬挂表的尾巴。(#18854中的@sebmarkpage)