大家好，我是Echa。
2023年9月份，Remix 研发团队历经千辛万苦正式发布了Remix 2.0 版本。Remix作为全栈Web框架，小编记得Remix 研发团队发布1.0版本的时候那时是2021年11月21日，这么算下来已经将近2年了。在Remix 官方的Github上面看，持续更新了19 个次要版本、100 多个补丁版本，并解决了数千个问题和拉取请求，终于迎来了Remix 2.0主要版本。未来全栈Web框架中也是妥妥的一匹黑马。
接下来小编带着大家一起详细了解全栈Web框架 Remix，希望对全栈Web框架程序员有所帮助，同时多一种新技能。
官网：http://remix.run/
Github：https://github.com/remix-run
Remix 是一款边缘原生的全栈 JavaScript 框架，用于构建现代、快速且有弹性的用户体验，它将客户端、服务器以及网站基础相结合，让用户可以专注于产品而非代码。
Remix 是一个由 React Router 开发团队所开发的基于 React 和 TypeScript 的全栈框架。2021 年 11 月，Remix 正式开源，至今已在 Github 上获得了 24.6k star。Remix 正式开源时，引发了前端圈不小的关注，其被普遍认为是 Next.js 的强劲对手，那时隔两年，它和 Next.js 之间的“竞争”怎么样了呢？
目前，Next.js 拥有 112k star，是 Remix 的近 5 倍。Next.js 周下载量 279 万，而 Remix 仅有 1.4 万，Next.js 是 Remix 的近 200 倍。可见，Remix 并没有像大家预料的那样，成为 Next.js 的有力竞争对手，在开发者社区中只有较小的市场份额。尽管如此，Remix 仍然吸引了一些开发者，并且在特定领域或项目中有其优势和适用性。
Remix 具有以下特性：
可以看出，Remix 用的是 HTML 的 ，而不是像 Next.js 一样用的内存缓存，因此，实际发出请求的是浏览器而不是 Remix。再看前面视频里用户中断当前的获取后，Remix 是如何取消请求的：完全不需要多一个字的代码就能优秀完成异步处理。
数据突变
在这一方面，可以说 Remix 和 Next.js 之间没有任何共同点了。既然应用程序的大半代码都与数据突变有关，那么为什么不让 web 框架也向它看齐呢？
Next.js 中的数据突变：无。，这行代码能解决一切。一般来说下，我们是通过管理表单状态来获取发布内容的，从添加一个发布用的 API 路由，到手动跟踪加载和错误状态、重新验证数据状态和其在整个 UI 中的传播变化，最后处理错误、中断和争用条件（不过说老实话，最后一条大概没几个人真的会去做）。
Remix 中的数据突变：Remix 用的是 HTML 表格。不过别着急下定论，Remix 的 API 完全可以处理当代 web 应用的需求，毕竟它的开发者全部的职业生涯都在和 web 应用高强度打交道。就算 Remix 看着像是老古董的 PHP，并不意味着它没办法适应现如今复杂多变的用户体验。对作者常常说，Remix 不仅可以扩展，还可以向下扩展。那么让我们回到美好的旧日子，更好地理解 Remix 的设计思路。
自互联网的诞生开始，突变都是借助表单和服务器页面来处理的。而如果完全不用 Remix，那么代码应该长这个样子：
// on the server at `/add-to-cart`
export async function action(request) {
let formData = await request.formData();
return addToCart(formData);
}浏览器用表单序列化后的数据通过 POST 导航到“/add-to-cart”页面，添加待定的用户界面，完成后再用数据库中的所有新数据渲染一个新页面。
Remix 和 HTML 表单的作用差不多，不过用首字母大写的
标签和一个 action 路由函数进行优化（如果说 Next.js 的页面也用自己的 API 路由……）。通过 fetch 发布而无需重新加载文档，让服务器重新验证页面上的所有数据以保持 UI 界面与后端保持同步。这一切都和开发者们在 SPA 里做的差不了多少，不过这里是 Remix 在帮忙管理了。
除了表单和服务端的操作之外，Remix 不需要应用程序的代码和服务器进行任何沟通，也不需要应用提供上下文或者全局的状态管理手段来将变化传递到 UI 的其他部分。这也是为什么 Remix 的打包比 Next.js 要小近 30%，毕竟 Remix 不需要用所有的代码来和那个“API 路由”对话。
不过话说回来，刚才那一串的代码确实可以在 Remix 里用上，如果用的是首字母小写的 标签，那么处理这些的将会是浏览器而不是 Remix。要是 JavaScript 没加载出来那这些将会派上大用场，具体的后面会详细说。
除此之外，我们还可以让 Remix 借助常用下拉框和已发布的进度和数据来优化 UI 并进一步扩展到高级的界面效果。这一系列操作中，HTML 表单是空白的画布，而绘制所依赖的则是设计师的灵感。如果说设计有了变化，页面的架构也不用有大改动。
更小的打包和更简单的突变 API 并不是 Remix 能做到的唯一事情。
因为 Remix 负责应用与服务器之间的所有互动，包括数据加载和突变，其在网络框架领域的独特能力可以应对网络的各种长期问题。
未处理错误
如果“添加到购物车”操作的后端处理程序抛出错误，那会发生什么？下面这个视频中，我们在向购物车添加物品时，拦截了到路由的请求，看看会发生什么。
错误处理非常难搞，和这里的处理一样，很多的开发者直接跳过了这一步骤，但作者觉得这样会导致糟糕的用户体验，所以让我们看看 Remix 在这一步是怎么做的：
Remix 的 POST 请求失败
Remix 可以处理应用中所有涉及数据和渲染的错误问题，即使这个错误是在服务器那边的。
开发者们所要做的就是在应用程序的底层定义一个错误边界，甚至进一步细化，只处理页面中出现错误的部分。
而 Remix 能做到而 Next.js 却不能原因只有一个，Remix 的数据抽象并没有停留在将数据引入应用程序这一层面，而是进一步拓展至数据的改变。
中 断
用户总是难免会在页面上同一个地方多点上几次鼠标，而多数的网页应用并不能很好地解决这个问题。但难免会有某个按钮，你会希望用户能够快速多次点击，并且网页 UI 也能立刻做出回应。
在我们的这个例子中，用户可以改变购物车中物品的数量，他们可能会想要快速增减数量。
让我们先看看 Next.js 的应用是如何处理中断问题的：
Next.js 的中断处理
事情发生太快很难看清到底发生啥了，但如果你左右调一下进度条，就会发现在第五六秒左右发生了很神奇的事情，不过最后几帧才是重头戏。可以看到，第四秒的时候最后发送的一个请求落地，而在几秒之后第一个请求才落地！而商品数量的变化则是“5-6-5-4-2”，期间完全没有用户互动，这种 UI 真的很让人头疼。
再看代码，也是没有任何对争用条件、中断或重新验证的处理，所以才会造成这种用户界面和服务器不同步的情况，而最终的商品数量是 2 还是 4 完全取决于最后到达服务端的到底是什么。如果代码里能够对中断和突变后的数据重新验证有一定的管理，那么将有效避免这种情况的发生。
有一说一，争用条件和中断要处理起来确实麻烦，所以大多数的应用程序都不愿意去做。即使是业内专业技术数一数二的 Vercel 开发团队也跳过了这一步。
无独有偶，在作者之前的一篇文章中也遇到过一样的情况，在移植 React Core 团队所搭建的 React 服务器实例时，他们也无视了争用条件和中断的处理。
那 Remix 是怎么做的呢？
Remix 的中断处理
可以看到在中断之后 Remix 便取消了请求，并且在 POST 完成之后又重新验证了数据。如此确保了不仅是这个表单，整个页面的 UI 都与服务器上的改变是同步的。
或许你会觉得是小编作弊了，毕竟他们在做的时候会投入更多的细节，而 Next.js 的应用只是个示例。但刚刚展示的这些特征并不是通过应用的代码实现，而是内置在它的数据突变 API 中的，Remix 其实做的仅仅是浏览器和 HTML 表单之间的互动。
小编认为，Remix 在客户端和服务器之间的无缝集成和过渡可以说是史无前例的。
升级的依赖要求
Remix v2已经升级了对React和Node的最低版本支持，并正式支持以下版本：
移除未来标志
以下未来标志已被移除，并且它们的行为现在是默认的，现在可以从remix.config.js文件中删除这些设置。
重大变更/API 删除
下面列出了 Remix v1 中具有弃用警告的其他重大更改/API 删除。如果使用的是最新1.19.3版本且没有任何控制台警告，那么可能可以继续执行所有这些操作！
（1）有破坏性更改/API移除
（2）没有弃用警告
此版本没能在每个破坏性更改或API移除上都收到废弃警告。以下是可能需要查看的剩余变更列表，以升级到v2：
（3）破坏类型变化
新增功能
其他更新
Remix 对于 React Server Components（RSC）的支持计划是积极的。他们希望在Remix v3中添加对RSC的支持，并希望能够展示这项技术在多个框架中的能力。
RSC是一个有趣且强大的功能，但是 Remix v2 是基于当前稳定的React特性构建的，因此 RSC 在 Remix v2 中尚未包含。一旦RSC稳定下来，Remix 将会支持它。
然而，与之前支持的其他React特性相比，“支持RSC”需要更深入的集成。RSC的异步组件与Remix的加载器和组件结合得非常相似，并且Remix在v3中决定摒弃使用第三方库useLoaderData，因此在数据加载方面可能会有所不同。他们希望开发者只需要将现有的加载器代码迁移到新的异步组件中，但需要注意数据依赖的瀑布效应。
Remix团队在今年早些时候的Remix Conf上与React核心团队的成员举办了一个讨论会，讨论了RSC以及如何共同推进这项技术的稳定发布。他们以各种方式帮助准备RSC，并希望能够成功地集成它到Remix中。
一台电脑,一个键盘,尽情挥洒智慧的人生;
几行数字,几个字母,认真编写生活的美好;
一 个灵感,一段程序,推动科技进步,促进社会发展。
创作不易，喜欢的老铁们加个关注，点个赞，打个赏，后面会不定期更新干货和技术相关的资讯，速速收藏，谢谢！你们的一个小小举动就是对小编的认可，更是创作的动力。
页面更新：2024-02-29
本站资料均由网友自行发布提供，仅用于学习交流。如有版权问题，请与我联系，QQ：4156828
© CopyRight 2008-2024 All Rights Reserved. Powered By bs178.com 闽ICP备11008920号-3
闽公网安备35020302034844号
