Remix v2

我们很高兴地宣布，在发布 Remix 版本 1 之后，经过近 2 年的持续努力——19 个次要版本，超过 100 个补丁版本以及数千个已解决的问题和拉取请求——我们今天将 Remix v2 发布到世界各地。

早在3 月份，我们详细讨论了我们对语义版本控制和构建稳定软件的看法，并描述了我们推进 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 年出现 Hook 时，它们为我们提供了一种不同的构建组件的方式，但它们对捆绑和应用程序部署的影响相对较小。但是，RSC 需要更深层次的集成。

自从我们最初评估 RSC 以来，我们对其发生的一些变化感到非常鼓舞。特别是，RSC async 组件看起来非常像 Remix loader 与组件结合，并决定放弃那个讨厌的第三者 useLoaderData。因此，您可以肯定数据加载在 Remix v3 中看起来会有所不同。我们希望您只需将许多 loader 代码移到新的 async 组件中即可（但要注意数据依赖级联！我已经说过这应该有它自己的帖子了吗？它确实应该……）。

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

这篇帖子的总结！说真的，我不知道你为什么还在看😅

去阅读升级指南！