提供fetch API后，RTK查询的实际需求是什么？

Question

最初的想法Flux是非常明显的。视图获取事件Actions，然后根据Action存储更新的事件发出事件。然而，当我通读时，redux-toolkit似乎有多种方法可以实现一些本来应该很简单的事情，即从端点获取 JSON 数据：

• 使用 fetch API 从端点获取一些数据
• 使用RTK查询做同样的事情
• 使用 React 上下文 API
• 使用useEffect()钩子

为什么有这么多不同的方法来完成最简单的任务？

谢谢。

Answer 1

这个问题隐藏了很多子问题，所以我会尝试根据我的经验回答所有这些子问题（我部分是 RTK Query 的粉丝）。

1. 要从浏览器通过 HTTP 请求资源，方法并不多，您必须使用xhrAPI fetch。 xhr是旧的基于回调的 API，fetch是现代标准的基于承诺的 API。
2. 在这些 API 之上，许多库的诞生是为了使流程和配置更容易/更广泛，今天您大多会直接使用fetch或使用一些黄金标准库，例如axios非常类似于fetch但它有一些很酷的额外功能来处理获取调用和配置。
3. 在像 React 这样的现代框架/库上，问题不是如何通过 HTTP 检索资源，而是如何处理异步调用以及响应对整个应用程序产生的副作用。
4. 现在，您可以选择几个选项。

基本上，对于非常基本的提取调用，如果是必须检索数据以在刚刚自动安装的组件内显示的 GET 调用，则可以在 useEffect 内处理该调用，或者在单击按钮时强制启动提取，例如如果它是 (通常）POST、PUT、ecc...调用。然后，您可以将结果保存在 React 状态中，并通过上下文将其传递到整个应用程序，以便其他组件访问收到的响应。顺便说一句，这会让您发现许多其他行为，第一个是调用期间的加载状态，以及错误状态响应或其他异常情况下的错误管理。这肯定是您可以使用 auseState或更好的 a来简单实现的东西useReducer钩子来简单实现的东西，所以这并不是您觉得需要像 RTK Query 这样的异步调用管理器的真正原因。

重新验证

例如，如果您在用户登录时执行后调用，返回带有用户数据的用户对象，您将该数据保存在客户端状态管理器（或 React state ）中，并使用该状态在您的应用程序中显示用户数据。整个应用程序。在使用应用程序期间，用户可以执行一些操作来更改数据库上的数据，因此每次他执行此操作时，您都必须小心，重新获取他的数据并更新他的客户端数据对象，或者从每个 POST/PUT/PATCH 等...调用并更新客户端状态，这很容易出错，因为如果您忘记在每次操作后更新客户端状态，或者如果有，您可能会发现自己有不同步的客户端/服务器端数据状态这些阶段中的一些问题。这通常会导致非常难以管理和调试的情况。我想说这是开始使用像 RTK 查询这样的Fetch 管理器的第一个充分理由。该管理器实现了一个非常简单的基于标签的重新验证机制，让您可以为您执行的每个查询（ GET ）分配一个标签，因此，例如，当用户登录时您将进行查询以检索用户数据，并且您将标记数据与. 现在，您可以安全地在后端对用户数据执行任意数量的突变，并且对于每个客户端，您将告诉它一旦收到响应，就必须重新验证某个标签（或多个标签）。例如，您可能有一个更改数据库内的用户密码的命令，您只需添加一个，这意味着一旦用户从服务器收到确认他更新了密码的肯定消息，客户端就知道它必须重新执行调用，获取新的用户数据，并将它们保存到 redux 全局存储中，这样所有使用它们的应用程序组件就可以立即访问它们。完全自动化。如果您自己实现整个机制，肯定需要您编写更多代码。providesTags: 'User'editPasswordMutationinvalidatesTags: 'User'getUserData

乐观的最新消息

大多数时候，您会发现自己不希望 UI 在显示（例如）按钮单击的效果之前等待服务器响应。想象一下，当您在 Facebook 上单击大拇指时，您会立即在 UI 中看到它，这并不是因为他们拥有超快的服务器，而是因为 UI 假设您单击按钮后调用就会成功，因此它会立即添加一个所显示帖子的点赞数+1。这种行为并非微不足道，因为通常当您在应用程序中显示数据时，您拥有并且应该拥有单一的事实来源。因此，例如，如果您要渲染博客文章列表，您应该从后端数据库中检索它们，将它们保存在客户端状态管理器中或直接按原样渲染它们。如果第一篇文章有​​，假设有 10 个赞，您将根据 来渲染它们data.posts[0].likes.count。所以这就是你的真相来源。如果您想添加一个Like/Dislike按钮，并且想要实现乐观更新，则必须手动更改该事实来源，这根本不好，因为它可以在多个组件之间共享（在全局状态的情况下）或复制它，并更改副本，但这也不好。复制事实来源几乎从来都不是一个好主意。RTK 查询来救援！使用 RTK 查询乐观更新设置起来非常简单，基本上每次获取都可以实现乐观更新行为，因为您可以使用生命周期方法onQUeryStarted来拦截调用的立即开始，然后使用实用程序：updateQueryData更新数据你的突变将会失效。非常聪明。因此，在这种情况下，您只需进行一个简单的突变，为博客文章添加一个“赞”，该突变将使数据无效posts，单个帖子将立即在 UI 中更新为 +1 个“赞”，同时服务器将重新获取帖子列表（因为它们已失效）和同步的新数据将被检索，用户会注意到非常流畅的体验。

还有许多其他功能，特别是涉及缓存管理，这是一个优点，（即使有时它们会产生一些问题），但我强调这两个主要功能，仅这两个功能就促使我成为 RTK Query 的用户，它可能看起来有点一开始很冗长，但它确实使事情变得非常干净整洁，与 Redux 哲学相一致。