Wagmi v2中useWalletClient和useConnectorClient的性能优化问题解析

问题背景

在Wagmi v2的使用过程中，开发者发现useWalletClient和useConnectorClient这两个钩子函数会导致过多的重新渲染，严重影响应用性能。经过深入分析，发现问题源于这些钩子内部实现中的查询失效逻辑。

核心问题分析

这两个钩子函数内部都包含一个useEffect，其逻辑如下：

useEffect(() => {
    // 当地址变化时使查询失效
    if (address) queryClient.invalidateQueries({ queryKey })
    else queryClient.removeQueries({ queryKey }) // 当账户断开连接时移除查询
}, [address, queryClient])

这段代码看似合理，但实际上存在一个关键问题：每当组件首次挂载时，这个效果都会运行，导致查询被不必要地无效化。这意味着：

1. 每次包含这些钩子的组件挂载时，都会触发查询无效化
2. 这会导致连锁反应，触发其他监听器/效果/订阅
3. 最终会调用createClient并生成新的uuid()
4. 这种模式很容易陷入性能陷阱

解决方案探讨

经过社区讨论，提出了几种改进方案：

方案一：使用ref跟踪地址变化

const prevAddress = useRef<UseAccountReturnType<config>["address"]>(address)

useEffect(() => {
  if (!address) {
    queryClient.removeQueries({ queryKey })
  } else if (address !== prevAddress.current) {
    queryClient.invalidateQueries({ queryKey })
  }
  prevAddress.current = address
}, [address, queryClient])

方案二：优化后的ref方案

const addressRef = useRef<Address | null | undefined>(null)

useEffect(() => {
  if (addressRef.current === null || addressRef.current === address) return
  
  if (address) queryClient.invalidateQueries({ queryKey })
  else queryClient.removeQueries({ queryKey })
  
  addressRef.current = address
}, [address])

技术实现要点

1. 首次渲染处理：通过ref初始值为null来区分首次渲染和后续更新
2. 变化检测：只有当地址实际发生变化时才执行查询操作
3. 性能优化：避免了不必要的查询无效化和重新渲染

最佳实践建议

1. 在使用这些钩子时，应注意其可能带来的性能影响
2. 对于频繁更新的组件，考虑使用ref方案优化
3. 在复杂应用中，可能需要考虑全局状态管理来减少重复查询

总结

Wagmi v2中的useWalletClient和useConnectorClient钩子函数在默认实现中存在性能隐患，通过引入ref来跟踪状态变化可以有效解决这个问题。这种优化模式不仅适用于Wagmi，也可以应用于其他需要精细控制副作用的React钩子场景中。