混音中的流式传输
混音中的流式传输
本文， 吉姆尼尔森 的 ” Remix 中的数据流 ”是文章的翻译。标有星号 (*) 的单词和术语的解释可在该段落下作为翻译说明获得。快乐阅读。
当 React 第一次出现时，它最有趣的特性之一就是“单向数据流”——单向数据流。这是 React 文档“ 在反应中思考 *”在该部分中仍然突出显示。
*Thinking in React：文档的土耳其语翻译 从这里 你可以到达。
分层的顶级组件 -component- 会将您的数据模型 -data model- 作为道具。更改基础数据模型
_根.render()_当您调用 时，UI 将被更新。您可以看到您的 UI 是如何更新的以及在哪里进行更改。反应的 只要 方向数据 flow（也称为单向绑定）确保一切都是模块化和快速的。
这个想法是数据只能在您的应用程序中以单向流的形式存在，这最终使您的应用程序更易于使用、理解和思考。
这种情况可以用以下语句来概括：“用户界面是状态的函数，或者换句话说， ui=fn（状态） .每当状态因动作而改变时，图像就会重新渲染。迄今为止，已经创建了许多先进的“状态管理”解决方案来开发具有这种心智
然而，这里很少承认的问题是，这种“单向数据流”有点名不副实。数据流， 在客户端 确实是片面的。但是仅在客户端上保存数据并不是很实用。很多时候，你需要持久化数据——为了同步它——这意味着你需要数据在两个方向流动：在客户端和服务器之间。
许多状态管理工具只帮助您管理客户端上的状态，但 网络鸿沟 它不会帮助你有效地通过。网络鸿沟：“客户端状态和服务器端状态之间的差距。”
混音进入现场 ：“Remix 的主要特点之一是简化与服务器的交互以将数据获取到组件中。” Remix 扩展了网络中的数据流，使其真正实现单向和循环：从服务器（状态）到客户端（图像-view-）再回到服务器（动作-action-）。
当说“您的 UI 是状态的函数”时，解决此语句中假设的更详细方法可能是：UI 远程状态 你的和 地方州 它是您的 .在传统的 React 应用程序中， 整个州 的位于客户端上，您想要永久保存的状态需要退出“单向数据流”并通过网络同步到服务器。可以想象，这也是一个容易出错的地方。
但是“UI 是状态的函数”的想法随着 Remix 的改变而改变，因为远程状态可以很容易地从本地状态中解析出来。 “有什么不同？”你在问吗？这样想吧。
任何应该持久的数据 -persistent- 偏僻的 状态 是：比如用户数据。此状态（例如，用户有多少未读通知？） 远离客户 被存储并且 装载机 -装载机- ve 行动 它通过 -actions*- 等 Remix 机制提供给您的应用程序。
*持久数据：“一种数据类型，在更改时会保留其更新版本，而不会破坏其先前版本。” 持久数据结构
*Loader：“每个路由都可以定义一个“加载器”函数，从服务器调用，以便在渲染之前向路由提供数据。此功能仅在服务器上运行。” 混音 |约定
*Action：“与加载程序一样，Action 是特定于服务器的功能，它的工作是处理数据交换和其他操作。如果你的路线 得到 如果请求不是 ( 发布、放置、修补、删除 )，然后在加载程序之前调用此操作。” 混音 |约定
( 不是 ：允许您通过 Remix 网络鸿沟，也在传输您的永久数据期间， 过渡 -过渡 - ve 发送的数据请求 它还通过 -fetchers- 提供有状态的*信息来提供帮助。 — 网络中每个请求的状态 正在加载 带有类似或的布尔值 初始 |加载 |成功|失败的 您不必自己跟进枚举，例如
*有状态：“状态由客户端存储，它创建一种数据供各种系统以后使用。” 有状态与无状态——概述
对此， 地方州 另一方面，它是临时的-ephemeral-数据，可能会丢失（例如，当您刷新页面时）而不会对用户体验产生不利影响*。这种状
*Temporary -ephemeral- data：以与持久数据类型相反的方式操作。 “传统的数据结构是短暂的，这意味着在对数据进行任何更新后，之前版本的数据都会丢失，只保留更新的版本。” 持久数据结构——简介
表单、提交的数据请求-fetchers-、loaders 和actions-loaders 和actions-都是Remix 的“状态管理”解决方案（尽管我们不这么称呼它们）。这些解决方案为您提供了在客户端和服务器之间保持持久状态同步的工具，确保您的应用程序和网络中的数据流是循环单向的：从加载器到组件到组件再到操作，然后再返回。
使用 Remix，您的 UI 不仅在本地 在网络上 也成为状态函数。 Remix 的数据抽象 有趣的类比 , React'in virtual DOM abstraction'ıdır.
使用 React 时，您不必费心自己更新 DOM。您指定状态，虚拟 DOM 进行所有比较 -diffing*- 以确定如何对 DOM 进行有效更新。 Remix 将这个想法扩展到了持久数据的 API 层。
*Diffing：“每当 UI 元素中发生状态更改时，都会创建一个新的虚拟 DOM。接下来，将新的和以前的虚拟 DOM 相互比较。” 解释 DOM 差异
使用 Remix，您不必担心保持客户端状态与服务器同步。您“创建”了一个要更改的状态，加载程序介入以重新请求最新数据并更新组件的映像 - 重新获取。
我希望这有助于解释 Remix 如何帮助大幅降低开发更好的网站所带来的复杂性。肯特的 在他关于 RenderATL 的演讲中 正如他所说，在 JavaScript 之前运行 Remix 对您的用户来说是一个胜利，因为他们正在体验由渐进增强提供支持的体验*。但这对开发人员来说也是一个胜利，因为您不必按照传统方式构建与状态管理解决方案相关的所有复杂性。
*渐进式增强： 混音内迪尔？第 -3 部分运输边缘
使用 Remix 时，您不必处理应用程序的状态管理。尽管它们是很酷的工具，但在使用 Remix 时你不需要 Redux 或 Apollo，因为我们甚至不需要客户端 JavaScript 来让一切正常运行...... [想想你正在开发的应用程序] 并假设你摆脱了所有负责管理应用程序状态的代码......这就是使用混音的方式。如果您的应用可以在没有 JavaScript 的浏览器中运行，这意味着您不需要任何需要在浏览器中进行状态管理的东西。
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明
