
本文详解如何利用 useSWR 的 compare 选项,在自动轮询(如每30秒)场景下,安全、可靠地获取前后两次请求中数组长度的变化量,并基于该差值实现新消息的渐进式展示。
本文详解如何利用 useswr 的 `compare` 选项,在自动轮询(如每30秒)场景下,安全、可靠地获取前后两次请求中数组长度的变化量,并基于该差值实现新消息的渐进式展示。
在使用 useSWR 进行定时轮询(如 refreshInterval: 30000)时,一个常见需求是:当服务端持续追加新消息(如 messages 数组每次新增 1–4 条),前端需感知“本次比上次多了几条”,进而触发动画、通知或分步渲染等交互逻辑。但直接在 useEffect 中对比 messages.length 存在风险——因为 messages 可能为 undefined(初始加载中)、null,或因重验证顺序导致前后状态错位;更关键的是,useEffect 无法天然访问“上一次有效数据”,容易引发竞态或误判。
幸运的是,SWR 提供了 compare 配置项——它是一个接收 (prevData, newData) 的纯函数,专为精确判定数据变更而设计,且在每次成功 revalidation 后、触发重新渲染前被调用。这正是我们捕获差值的理想钩子。
✅ 正确做法:用 compare 捕获长度差并同步状态
import useSWR from 'swr';
const fetchMessages = () => fetch('/api/messages').then(r => r.json());
const MessageList = () => {
const [newItemCount, setNewItemCount] = useState(0);
const [messages, setMessages] = useState<string>([]);
// 核心:在 compare 函数中计算差值并更新状态
const { data, error, isLoading } = useSWR(
'/api/messages',
fetchMessages,
{
refreshInterval: 30000,
// ? 关键配置:访问 prevData 和 newData
compare: (prevData, newData) => {
// 安全校验:仅当两者均为有效数组时计算差值
const prevLen = Array.isArray(prevData?.messages)
? prevData.messages.length
: 0;
const newLen = Array.isArray(newData?.messages)
? newData.messages.length
: 0;
const diff = Math.max(0, newLen - prevLen);
setNewItemCount(diff); // 立即更新差值状态
setMessages(newData?.messages || []); // 同步最新数据(可选)
// 返回 true 表示数据已变更,触发组件 rerender
return diff > 0 || prevLen !== newLen;
}
}
);
// ? 注意:不要在此处用 useEffect 直接对比 messages.length!
// 因为 messages 是响应式状态,其更新可能滞后于 compare 执行时机,导致取到旧值。
if (error) return <div classname="error">加载失败</div>;
if (isLoading || !data) return <div>加载中...</div>;
return (
<div>
<p>本次新增消息数:<strong>{newItemCount}</strong></p>
<ul>
{messages.map((msg, i) => (
<li key="{i}" classname="{i">= messages.length - newItemCount ? 'new' : ''}>
{msg}
</li>
))}
</ul>
{/* 示例:基于 newItemCount 实现逐条淡入 */}
{newItemCount > 0 && (
<newmessageanimator messages="{messages.slice(-newItemCount)}" duration="{30000" newitemcount></newmessageanimator>
)}
</div>
);
};</string>
⚠️ 重要注意事项
-
compare不用于触发副作用:它应保持纯净(无setState以外的副作用),且必须返回布尔值(指示是否触发重渲染)。虽然我们在其中调用了setNewItemCount,但这属于合法的状态同步,前提是不引发无限循环(本例中newItemCount不参与 SWR key 或 fetcher,故安全)。 -
避免
useEffect重复对比:原问题中尝试在useEffect([messages])中计算差值,但messages是当前最新值,无法回溯“上一次”长度;且useEffect在compare之后执行,此时prevMessagesLength已不可得。compare是唯一能同时拿到新旧数据的官方机制。 -
结构兼容性:若 API 返回结构为
{ messages: string[] },请确保prevData和newData解构一致;建议添加类型守卫(如Array.isArray())防止运行时错误。 -
性能提示:
compare函数会频繁调用,请保持轻量。长度差计算复杂度为 O(1),符合要求。
✅ 总结
要稳健实现“轮询差值感知”,请放弃手动缓存 prevLength 或依赖 useEffect 对比,转而拥抱 SWR 原生的 compare 选项——它既是数据变更的权威判据,也是新旧数据交汇的安全通道。结合 useState 同步差值,你就能精准驱动增量 UI 更新,让每一条新消息都以可控节奏抵达用户眼前。










