Remix v2

我们很高兴地宣布，在自 Remix 第 1 版发布以来，经过近 2 年的持续努力（19 个小版本发布、超过 100 个补丁版本发布以及数千个已关闭的问题和拉取请求）后，我们今天正式发布 Remix v2。

早在 三月份，我们详细讨论了我们对语义版本控制和构建稳定软件的看法，并描述了我们在发布新的主要版本时，如何推进 Remix 的发展，而无需您重写应用程序的方法。今天，我们正在兑现这一承诺。如果您的 Remix v1 应用程序启用了所有未来标志，那么您只需从 Remix 配置中删除这些标志，即可几乎无缝地升级到 v2。当然，这是一个主要版本，因此我们也借此机会升级了一些主要依赖项（特别是 React 18 和 Node 18）。

有关您需要升级的内容的全面演练，请参阅我们的升级到 v2 的指南。

我们希望您确信，您在其上构建业务的软件不会在明年让您措手不及。换个角度考虑：如果您一直在使用 Remix v1 中的未来标志，那么您在几个月前就已经可以使用 Remix v2 中的许多功能了。这是我们多年来从许多智者那里学到的迭代软件开发生命周期，对此我们深表感谢。Remix v3 也将以相同的方式进行开发。现在 v2 已经发布，您可以期望 v3 的功能将在未来几个月内在稳定/最终 v3 版本发布之前，出现在未来标志后面。

亮点

如果您尚未关注，以下是我们已在 v1 中发布的一些亮点

• 在 v1.8 和 v1.10 中，我们将 Remix 与 React Router v6 对齐。当我们开始开发 Remix 时，我们承诺它将使 React Router 更好。此版本真正完成了该承诺，并将这两个库对齐以使用相同的底层依赖项。
• 在 v1.11 中，我们发布了 defer，我们亲切地称之为“通过网络传输的 Promise”。现在，如果您真的想念它们，您可以将加载指示器放回您的 Remix 应用程序中了！😜
• 同样在 v1.11 中，我们添加了“扁平”路由，简化了嵌套布局的实现，而无需嵌套目录。这是 v2 中的默认设置
• 在 v1.13 和 v1.16 中，我们发布了对 Remix 中各种 CSS 策略的极大改进，包括 PostCSS、CSS 模块、Vanilla Extract 和 CSS 副作用（全局）导入。
• 在 v1.14 和 v1.18 中，我们发布了一个新的开发服务器，它同时支持热模块重载 (HMR) 和热数据重载 (HDR)。新的开发服务器是 v2 中的默认设置。

此外，我们在 v2 中发布的主要亮点之一是 全新的 create-remix CLI 体验。

有关 v2 中所有更改的完整列表，请参阅发行说明。

关于 RSC 呢？

这真的值得单独写一篇文章，但我知道你们中的一些人可能想知道 Remix 在 React 服务器组件 (RSC) 方面有什么计划。这是一个很好的问题，如果您读到这里，您可能也会有这个问题，所以我将尽力告诉您我们现在的处境。

简而言之，我们对在 Remix v3 中添加对 RSC 的支持持乐观态度，并且我们渴望在多个框架中证明这项技术发挥作用。RSC 的功能很有趣，但是 Remix v2 依赖于当前稳定的 React 功能，在撰写本文时，这些功能不包括 RSC。当 RSC 稳定时，您可以期望 Remix 会支持它。

但是，“支持 RSC”与我们见过的支持其他 React 功能有很大不同。例如，当钩子在 2018 年出现时，它们为我们提供了构建组件的不同方式，但是它们对捆绑和应用程序部署的影响相对较小。但是，RSC 需要更深入的集成。

自从我们最初评估以来，我们在 RSC 中看到的一些变化非常鼓舞人心。特别是，RSC async 组件看起来很像 Remix loader 与组件结合，并决定抛弃那个讨厌的第三者 useLoaderData。因此，您可以确信数据加载在 Remix v3 中会看起来有所不同。我们希望您只是将大量的 loader 代码移动到新的 async 组件中（但请注意数据依赖瀑布！我是否已经提到这应该是一篇单独的文章？确实应该...）。

在今年早些时候的 Remix Conf 上，我们主持了 与一些核心 React 团队的讨论会，我们在会上讨论了 RSC 以及我们如何一起工作。我们渴望尽我们所能帮助这项技术做好稳定发布的准备。

好啦，这篇文章就到此结束！说真的，我不知道你为什么还在这里 😅

快去阅读升级指南！