React实时通知与异步竞态处理

上一篇 · 返回目录 · 下一篇

为什么需要RealtimeProvider

如果每个页面都创建 socket，会出现重复连接、重复事件和清理困难。项目把连接放在登录成功后的 RealtimeProvider：未登录时没有实时连接；登录使用者变化时旧会话必须完整销毁。

export function RealtimeProvider {
return {children};}

key={user.id} 很关键。React 在账号切换时卸载旧RealtimSession，再挂载全新实例。notifications、去重集合、generation和socket都不会跨使用者复用。

创建连接与注册监听

const socket = io(apiBaseUrl。{
withCredentials: true,autoConnect: true,transports:,});socket.on，socket.on;socket.on，socket.on;

effect cleanup 必须逐一 off，并调用 disconnect。否则组件重新挂载后旧回调仍可能更新状态或制造重复toast。

一个事件产生两种结果

const handleMembershipCreated = => {
if (
generation!== generationRef.current ||
seenEventIds.current.has
) return;怎么说呢，seenEventIds.current.add;setNotifications => );setTeamRefreshVersion => current + 1);}，

notifications驱动通知中心，给使用者立即反馈；teamRefreshVersion是失效信号，WorkspacePage观察到变化后重新GET /api/teams。事件没有直接修改团队列表。

eventId Set防止同一事件重复生成toast。使用函数式setState则避免多个事件在同一渲染周期内互相覆盖。说起来，

teamRefreshVersion 为什么是数字

布尔值只能表达“要刷新/不要刷新”。两个连续事件可能都写true，第二次不会触发依赖变化。单调递增版本能表达每次变化。

但版本号也不代表着页面必须并发发送一样多的GET。WorkspacePage使用single-flight与queued catch-up：加载中又收到刷新，只记录还需要追赶；当前请求结束后再补一次避免请求风暴，同时保证最终读到更晚快照。

首次连接失败与重连要区分

首次连接失败 -> 后来第一次成功 -> 需要同步快照已经连接 -> disconnect -> reconnect -> 需要同步快照首次直接成功 -> 页面已有正常初始加载 -> 不额外重复同步

Provider 用hasConnected、initialConnectionFailed和reconnecting区分这些方法。老实说，每次可能存在消息缺口的恢复都会增加teamRefreshVersion。

generation防止旧回调污染

effect创建时捕获generation。cleanup先递增generation，再移除监听和断开连接。即使测试环境或第三方库晚到地调用旧handler，比较失败后也不会写入当前状态。

这种“上下文令牌”模式一样适合普通请求：请求开始时捕获使用者ID、团队ID和版本；老实说，响应回来时只有上下文仍匹配才允许写UI。其实，

从痛点来看。邀请按钮长期卡在“邀请中”

• 双击在React提交状态渲染前可能发出两个POST；
• A请求pending时切到B。A的finally可能把B的按钮解锁，或A的成功把成员B。

项目使用同步ref阻止同一提交窗口的重复请求，并用invitationGenerationRef与originatingTeamId判断响应是否仍属于当前页面。success、catch、finally都必须守同一上下文边界，不能只保护成功分支。老实说，

痛点的观点是。A → B → A 更难

• 只比较teamId无法识别ABA场景：请求开始于A路由切到B路由又切回A旧响应回来时teamId仍是A;
• "generation"递增可防止旧A响应成新A请求;
• A请求成功后若已回到A，则需保留该业务事实不可直接丢弃新输入或错误提示——实现将“当前token的成功”与“当前显示团队的旧成功对齐”分开处理。

痛点的观点是。实时刷新与本地创建团队竞争

• A正在POST创建团队，同时实时事件触发GET /api/teams。其实，如果GET旧快照最终返回，可能把刚创建的团队覆盖掉;

• Solve：
  • GET 用request generation防止旧快照覆盖;
  • 本地mutation成功使旧load失效，必要时追加一次刷新;
  • 加载期间多个实时刷新合并，但至少执行最终追赶;
  • 错误只由当前上下文请求显示.

再看痛点，前端可见状态与服务器事实混淆

• 按钮busy、表单输入、错误提示属于某次前端操作；成员关系和团队列表属于服务器事实。旧请求成功可以触发数据重新对齐，但不应控制当前操作的busy/error/input。此划分是解决复杂竞态关键.

常见错误

1. 在组件函数体直接创建 socket：每次渲染都会新增连接；auto-connect 的副作用导致频繁重连.
2. cleanup只disconnect不off：旧回调仍可能被mock或库内部队列触发;其实，and may lead to stale state updates.
3. 用数组includes去重：对象引用不同。无法识别相同 eventId;and leads to duplicate notifications. auto‑reconnect might replay events. cannot rely solely on payload. bad performance. nice. canceling.
elso.\t\u200b
4. 事件到达就完全信任payload：无法补偿断线漏失，也拿不到完整权威快照;and may show stale data. but sometimes you get duplicates. could lead to inconsistent UI. automatically lost events cause missing updates. client might think it's up‑to‑date when it's not.

   ---