[RFC] 049 - 乐观更新改造

[arvinxx]

背景

在做 #1851 的实施过程中发现， 在 client DB 请求响应非常敏捷的情况下（~ 30ms），大量中间态都被忽略了。而换成 serverDB 后，网络请求的延迟变得不可忽略（300ms ~ 2s）。因此需要对应适配服务端操作的逻辑，才能确保体验优良。

对应的适配策略有两个，一个是加 loading 态，另外一个就是乐观更新。

简介：什么是乐观更新

by GPT-4-turbo

乐观更新（Optimistic UI Update）是一种在前端开发中常用的技术策略，用于提升应用程序的用户体验。当应用程序需要与服务器进行数据交互时，乐观更新策略假设这些交互会成功，并立即在用户界面上反映这些变更，而不是等待服务器响应。这种方法可以使应用感觉更快，因为它减少了用户等待服务器响应的时间。

乐观更新的工作原理：

1. 用户操作：用户执行一个操作，比如点击“保存”按钮保存表单数据。
2. 立即更新UI：应用程序立即将这些更改反映到用户界面上，而不是等待服务器的确认。
3. 发送请求到服务器：同时，应用程序会将数据异步发送到服务器进行更新。
4. 处理响应：
   • 成功响应：如果服务器成功处理了请求并返回成功响应，应用程序可能会在后台进行轻微的状态更新或者不做任何操作，因为用户界面已经显示了预期的状态。
   • 失败响应：如果服务器返回错误或操作失败的响应，应用程序需要处理这种情况，通常是通过回滚用户界面到操作前的状态，并可能显示错误消息给用户。

使用乐观更新的优点：

• 改善用户体验：用户不需要等待服务器响应，从而感觉应用响应更快。
• 减少感知的延迟：即便网络延迟或服务器处理较慢，用户也不会感觉到卡顿。

使用乐观更新的缺点：

• 复杂的错误处理：开发者需要仔细设计错误处理逻辑，确保在操作失败时能够恢复到原始状态。
• 可能的数据不一致：如果多个操作几乎同时发生，并且依赖于服务器的响应来维持一致性，乐观更新可能会导致问题。

应用场景：

乐观更新特别适用于那些对实时性要求较高的应用，如在线协作工具、社交网络应用等。在这些应用中，快速响应用户操作并保持界面流畅是非常重要的。

总之，乐观更新是一种有效的前端策略，可以显著提高应用的响应性和用户满意度，但同时它也要求开发者在实现时仔织考虑错误处理和数据一致性问题。

设计思路

基本 case

乐观更新主要存在用户操作层面，例如 增删改等操作，核心需要做的事情就是采用前端状态先行变更， 然后再派发请求。以 userStore 的 updatePreference 为例，实现如下：

  updatePreference: async (preference, action) => {
    // 1. 计算终态数据
    const nextPreference = merge(get().preference, preference);

    // 2. 前端状态变更
    set({ preference: nextPreference }, false, action || n('updatePreference'));

    // 3. 触发服务端变更
    await userService.updatePreference(nextPreference);
  },

如果存在更新失败的场景，还需要 try catch await 做对应的状态回滚，但限于工作量问题，本次暂时先不做，后续再补上。

数据展示类变更

如果是针对展示类数据的变更，往往还需要 loading 态并搭配一次 refresh 数据。以 topic 为例:

  internal_updateTopic: async (id, data) => {
    // 1. 前端更新状态
    get().internal_dispatchTopic({ type: 'updateTopic', id, value: data });

    // 2. 变更加载态为 true
    get().internal_updateTopicLoading(id, true);

    // 3. 触发更新，并触发刷新列表
    await topicService.updateTopic(id, data);
    await get().refreshTopic();

    // 4. 完成后取消加载态
    get().internal_updateTopicLoading(id, false);
  },

表单类

针对表单类输入的场景，常见的做法是加一个确认按钮，但是我们期望尽可能做成实时的效果，因此仍然采用 clientDB 模式下那种变更后就触发更新的模式。而这种情况下就会出现比较严重的请求竞态问题。 比较典型的情况就是用户输入完毕 'abcdefg'，等待一会结果变成了 'abc' 。

请求竞态（Request Race Condition）是指在并发或者异步环境中，多个请求同时发起，但完成的顺序无法预测，导致最终的应用状态不确定或错误的情况。这种问题常见于网络应用和多线程编程中，尤其是在处理数据库写入、文件更新时。如果不妥善处理请求竞态，可能会导致数据损坏或者业务逻辑错误。为避免这种情况，开发者可以采用锁机制、事务控制或者确保请求序列化等策略来管理并发请求，保证数据的一致性和正确性。

而解决方案就是发起新的请求时自动取消上一个更新请求，始终确保用户最后的操作是最终的更新请求。

  setSettings: async (settings) => {
    // ******** 1. 终态数据处理  ******** //
    const { settings: prevSetting, defaultSettings } = get();

    const nextSettings = merge(prevSetting, settings);

    if (isEqual(prevSetting, nextSettings)) return;

    const diffs = difference(nextSettings, defaultSettings);

    // ******** 2. 乐观更新前端状态  ******** //
    set({ settings: diffs }, false, 'optimistic_updateSettings');

    // ******** 3. 自动取消前一个更新请求  ******** //
    const prevAbortController = get().updateSettingsSignal;
    if (prevAbortController && !prevAbortController.signal.aborted) prevAbortController.abort('canceled');

    const abortController = new AbortController();

    set({ updateSettingsSignal: abortController }, false, 'signalForUpdateSettings');

    // ******** 4. 触发更新请求并刷新  ******** //    
    await userService.updateUserSettings(diffs, abortController.signal);
    await get().refreshUserState();
  },

Important

可能有人会问为何不用 useSWR 内置的乐观更新能力，原因是 useSWR 对于数据的定制能力实在有限，而我们的场景由于交互复杂度的关系，存在大量的自定义数据控制流，因此不可行。（比如上述表单类的竞态控制就做不到）

进展

• Session/SessionGroup
  • ♻️ refactor: refactor for session server mode #2163
  • 💄 style: improve aync session experience #2075
• Topic
  • ⚡️ perf: refactor to improve the topic in server mode #2182
• Message
  • ⚡ perf: improve message loading #2097
• Agent
  • Agent Store ♻️ refactor: sperate SessionStore to a new AgentStore #2197
• User
  • Preference ♻️ refactor: rename globalStore to userStore #2264
  • Settings: ♻️ refactor: add optimistic updating to user setting #2709