React-query解决你一半的状态管理问题

数据通常作为「状态」保存在组件内部(如App组件的data状态)。

如果是需要复用的通用「状态」，通常将其保存在Redux这样的「全局状态管理方案」中。

这样做有2个坏处：

1.需要重复处理请求中间状态

为了让App组件健壮，我们还需要处理请求中、出错等中间状态：类通用的中间状态处理逻辑可能在不同组件中重复写很多次。

2.「缓存」的性质不同于「状态」

不同于交互的中间状态，服务端状态更应被归类为「缓存」，他有如下性质：

• 通常以「异步」的形式请求、更新
• 「状态」由请求的数据源控制，不由前端控制
• 「状态」可以由不同组件共享

作为可以由不同组件共享的「缓存」，还需要考虑更多问题，比如：

• 缓存失效
• 缓存更新

Redux一把梭固然方便。但是，区别对待不同类型「状态eact-Query中的Query指一个异步请求的数据源。

例子中userData字符串就是这个query独一无二的key。

可以看到，React-Query封装了完整的请求中间状态(isLoading、isError...)。

不仅如此，React-Query还为我们做了如下工作：

• 多个组件请求同一个query时只发出一个请求
• 缓存数据失效/更新策略(判断缓存合适失效，失效后自动请求数据)
• 对失效数据垃圾清理

数据的CRUD由2个hook处理：

• useQuery处理数据的查
• useMutation处理数据的增/删/改调用mutate方法，会触发请求。

  当请求成功后，会触发onSuccess回调，回调中调用queryCache.invalidateQueries，将userData对应的query缓存置为invalidate。

  这样，React-Query就会重新请求userData对应query的数据。

  总结

  通过使用React-Query(或SWR)这样的数据请求库，可以将服务端状态从全局状态中解放出来。

  这为我们带来很多好处：

  • 使用通用的hook处理请求中间状态
  • 多余请求合并
  • 针对缓存的更新/失效策略
  • Redux等「全局状态管理方案」可以更专注于「前端中间状态」处理
  • 

（编辑：开发网_开封站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!