在现代 Web 开发中，提供流畅且响应迅速的用户体验至关重要。 最终用户可能没有注意到的一个方面是应用程序如何处理正在发生变化的数据，即创建、更新和删除。
这可能是由于此功能的双重性质：如果效果好，没有人注意到；如果效果好，则没有人注意到；如果没有，则该应用程序被认为是一个糟糕的应用程序。
用户希望感觉他们可以控制他们正在做的事情。应用程序中几乎每个加载状态都有可能分散用户的注意力，他们需要等待操作完成。但这就是应用程序应该如何工作，对吧？
如果您的应用程序可靠且运行良好，您可能已经注意到大多数更改服务器中数据的请求都是成功的。即使大多数应用程序在变异时使用加载状态，然后在收到响应时显示更新的数据。
今天我将向您解释您可以使用哪些选项来改善此用户流程以及为什么使用它们。 然后，我将向您展示每个方法的代码示例以及逐步实现。继续阅读！
传统方法
最常用和最传统的改变数据的方法是 Pessimistic UI。
悲观 UI 是 UI/UX 设计中的一种方法，用户所做的更改在收到并确认服务器响应之前不会立即反映在屏幕上。
当用户执行提交表单或点击按钮等操作时，界面将保持不变，直到从服务器收到响应。在此期间，用户可能会看到加载指示器和被阻止的按钮或输入。收到响应后，UI 将更新为新数据或给出反馈。
这种悲观的方法在数据一致性和准确性很重要的情况下被采用并很有用。 通过将 UI 更新推迟到响应得到验证，可以减少显示不正确和不一致数据的可能性。
悲观 UI 使用的一些示例是银行交易和应用程序登录和注册，其中安全性和一致性优于响应式界面。
但有时我们需要给用户更多的控制感，同时提供更流畅的应用体验。
想象一下，如果您每次喜欢 Instagram 帖子时都会看到一个加载旋转器。这绝对不理想，您不会完全参与整个应用程序体验。
为了解决这个问题，我们有 Optimistic UI。
了解乐观用户界面
Optimistic UI 是一种旨在向用户提供即时反馈， 然后在后台触发变更请求的方法。
当执行诸如单击按钮或提交表单之类的操作时，界面将在发送实际请求之前更新，因此用户可以继续浏览应用程序。同时，服务器正在处理请求并最终将响应返回给前端。如果响应失败，则 UI 更新将回滚，如果响应成功，则无需执行任何操作 — UI 已更新。
Optimistic UI 方法用于反馈和响应至关重要的场景。 它消除了任何感知到的延迟，并通过预先假设成功的响应来创建更流畅的用户体验。****
如上所述，Optimistic UI 的一个示例是 Instagram 点赞按钮。单击按钮（喜欢或不喜欢）时，会预先更新 UI，然后发送请求。这也很棒，因为有些用户可能使用的是慢速网络，因此在这种情况下，Optimistic UI 是一个问题解决者。
现在您了解了每种方法的区别和用例，让我们深入研究一些代码示例。
我们示例的场景
在进入代码之前，让我向您展示我们将在所有示例中使用的内容。
让我们考虑一个简单的 React 应用程序，它有一个“发送消息”按钮，当单击该按钮时，它会向服务器发送一个请求，然后将一条新消息添加到列表中。此外，当用户进入页面时，应从 API 获取现有消息。
为了模拟 API 请求，将解决承诺并为其添加延迟，因此您可以更好地理解整体行为。这是我们将要使用的两个模拟 API 请求
// Default existing messages
const messages = [
{
id: 1,
message: "Existing message",
},
{
id: 2,
message: "Existing message",
},
];
// Return all the messages
export const getMessages = () =>
new Promise((resolve) => {
setTimeout(() => {
resolve(messages);
}, 1500);
});
// Add a new message to the messages array
export const sendMessage = (message) =>
new Promise((resolve) => {
setTimeout(() => {
messages.push(message);
resolve(messages);
}, 1500);
});
对于样式，我将使用TailwindCSS。
没有反应查询的悲观更新
为了使这项工作正常进行，我们需要管理加载行为并将新消息添加到状态。这基本上是大多数应用程序在幕后所做的。
const PessimisticUpdate = () => {
const [isFetching, setIsFetching] = useState(false); // Used for initial fetching
const [isLoading, setIsLoading] = useState(false); // Used when sending a new message
const [messages, setMessages] = useState([]); // Local state to store messages
// Load existing messages from API when component mounts,
// and shows a loading state while fetching
useEffect(() => {
setIsFetching(true);
getMessages().then((messages) => {
setMessages(messages);
setIsFetching(false);
});
}, []);
const handleClick = () => {
setIsLoading(true); // Enable loading
const newMessage = {
id: messages.length + 1,
message: "New message",
};
// Dispatch API request to add the new message
sendMessage(newMessage).then((updatedMessages) => {
setMessages(updatedMessages); // Update messages in the local state
setIsLoading(false); // Disable loading
});
};
return (
<>
{!isFetching && <MessagesList messages={messages} />}
<Button
text="Send message"
onClick={handleClick}
isLoading={isLoading || isFetching}
/>
</>
);
};
请注意，反馈isLoading——仅在承诺解决后才定义。
没有 React 查询的乐观更新
这里最大的区别是我们不再需要了isLoading，因为我们预先考虑发送消息时一切都会正常工作，所以 UI 反馈将是即时的，并且不需要加载状态。
const OptimisticUpdate = () => {
const [isFetching, setIsFetching] = useState(false); // Used for initial fetching
const [messages, setMessages] = useState([]); // Local state to keep messages
// Load existing messages from API when component mounts,
// and shows a loading state while fetching
useEffect(() => {
setIsFetching(true);
getMessages().then((messages) => {
setMessages(messages);
setIsFetching(false);
});
}, []);
const handleClick = () => {
const newMessage = {
id: messages.length + 1,
message: "New message",
};
// Update message in the local state upfront
setMessages((previousMessages) => [...previousMessages, newMessage]);
// Then dispatch API request to add new message
sendMessage(newMessage).then(() => {
console.log(`Message ${newMessage.id} added`);
});
};
return (
<>
<h1 className="font-bold text-xl mb-2 text-center">Optimistic UI</h1>
{!isFetching && <MessagesList messages={messages} />}
<Button
text="Send message"
onClick={handleClick}
isLoading={isFetching}
/>
</>
);
};
对于用户体验方面的重大改进来说，这是一个很小的变化。虽然有一些权衡取舍。
我们不考虑请求是否失败。在某些情况下，从状态中删除无效数据并不简单，需要手动完成。您可能只需要添加另一个状态来保留临时消息，以及包含实际消息的状态。
考虑到真实世界的应用程序要处理的事情要多得多，您还需要确保回滚所有 UI 更改，并在请求失败时分派正确的操作。这可能有点棘手，并且可能涉及一些复杂性。
使用 React 查询进行悲观更新
这里最大的区别是 React Query 管理所有与消息和请求相关的状态。它不是直接在组件中调用服务，而是传递给 React Hook 并立即调用。
const PessimisticUpdateReactQuery = () => {
const cacheKey = "messages"; // Cache key of the messages
const queryClient = useQueryClient();
// Load existing messages from API
const { data: messages, isLoading: isFetching } = useQuery(
cacheKey,
getMessages
);
// Dispatch API request to add new message
const { mutateAsync, isLoading } = useMutation(sendMessage, {
onSuccess: () => {
// Invalidate messages cache, since a new message was added.
// The `messages` var will be automatically updated with fresh data.
queryClient.invalidateQueries(cacheKey);
},
});
const handleClick = () => {
const newMessage = {
id: messages.length + 1,
message: "New message",
};
// Call React Query hook that calls sendMessage
mutateAsync(newMessage);
};
return (
<>
{!isFetching && <MessagesList messages={messages} />}
<Button
text="Send message"
onClick={handleClick}
isLoading={isLoading || isFetching}
/>
</>
);
};
代码更容易阅读，因为很多东西都被库抽象了。
您还将拥有开箱即用的缓存。如果再次调用同一服务，React Query hook 将返回缓存的值，而不是进行新的 API 调用，您可以根据需要配置缓存时间。这是一个很大的性能改进。
使用 React 查询进行乐观更新
正如上面示例中所讨论的，React Query 将处理所有服务器状态， 您不需要管理useState来自 React 的任何内容。
这里我们有处理乐观更新的最佳版本。所有的行为都由 React Query 负责，所以我们只需要调用它的 API。
下面的代码乍一看可能令人困惑，但让我们深入研究它并了解所做的所有更改：
const OptimisticUpdateReactQuery = () => {
const cacheKey = "messages"; // Cache key of the messages
const queryClient = useQueryClient();
// Load existing messages from API
const { data: messages, isLoading: isFetching } = useQuery(
cacheKey,
getMessages
);
// Dispatch API request to add new message
// and do the optimistic update.
const { mutateAsync } = useMutation(sendMessage, {
onMutate: async (newMessage) => {
// Cancel any outgoing refetches (so they don't overwrite the optimistic update)
await queryClient.cancelQueries(cacheKey);
// Snapshot the previous value
const previousMessages = queryClient.getQueryData(cacheKey);
// Optimistically update to the new value
queryClient.setQueryData(cacheKey, (old) => [...old, newMessage]);
// Return a context object with the snapshotted value
return { previousMessages };
},
onError: (_, __, context) => {
// If the mutation fails, use the context returned from onMutate to roll back
queryClient.setQueryData(cacheKey, context.previousMessages);
},
onSettled: (messages) => {
// Always refetch after error or success:
queryClient.invalidateQueries(cacheKey);
console.log(`Message ${messages[messages.length - 1].id} added`);
},
});
const handleClick = () => {
const newMessage = {
id: messages.length + 1,
message: "New message",
};
mutateAsync(newMessage);
};
return (
<section>
{!isFetching && <MessagesList messages={messages} />}
<Button text="Send message" onClick={handleClick} />
</section>
);
}
如前所述，这具有很多优点，例如缓存、自动失效和重新获取。
在这种情况下，一个好主意是将乐观行为（在 下onMutate）抽象为一个自定义挂钩，然后您可以调用这个具有乐观特征的挂钩。钩子可以是这样的：
const useOptimisticUpdate = () => {
const queryClient = useQueryClient();
const getPreviousData = async ({ cacheKey, newValue }) => {
await queryClient.cancelQueries(cacheKey);
// Snapshot the previous value
const previousData = queryClient.getQueryData(cacheKey);
// Optimistically update to the new value
queryClient.setQueryData(cacheKey, (old) => [...old, newValue]);
// Return a context object with the snapshotted value
return { previousData };
};
return { getPreviousData };
};
然后onMutate用钩子替换调用：
const OptimisticUpdateReactQuery = () => {
// ...
const { getPreviousData } = useOptimisticUpdate(); // New hook call
const { mutateAsync } = useMutation(sendMessage, {
onMutate: async (newMessage) => ({
previousMessages: await getPreviousData({ // Get previous data from the hook
cacheKey,
newValue: newMessage,
})
}),
// ...
现在你有一个可重用的乐观更新功能，可以在你需要的每个组件之间共享。
总结
许多类型的应用程序提供的体验可能始终以最终用户为中心。这就是 Optimistic UI 的亮点所在。
乐观更新通过在数据更新期间提供即时反馈和响应显着改善用户体验。传统方法需要手动状态管理和错误处理，而 React Query 通过提供内置突变函数、自动缓存失效和错误处理简化了该过程。通过利用 React Query，您可以通过更流畅的用户体验增强应用程序，节省手动管理数据更新的时间和精力。
需要考虑的一件事是，并非每个案例都适合这个概念，有时出于多种原因（例如安全性和数据一致性）使用悲观 UI 会更好。
仔细考虑在哪里应用一个或另一个概念，并考虑与设计师和 PO 讨论这个决定。他们可以提出其他观点，因为这个决定在很大程度上取决于用户体验。
