Skip to content

Latest commit

 

History

History
163 lines (115 loc) · 5.75 KB

useXS-zh_CN.md

File metadata and controls

163 lines (115 loc) · 5.75 KB

English | 简体中文

useXS

React Hooks remote data fetching method

Quick Start

import {useXS} from "xswr"

function Account() {
  const account = useXS("/api/account", fetcher, {
    shouldComponentUpdate: false
  })

  const assets = useXS(
    () => {
      const {assetsId} = account.data
      return ["/api/assets", {id: assetsId}]
    },
    (url, params) => {
      return fetch(url, params)
    },
    [account]
  )

  const {data, error, isValidating} = assets

  if (error) return <div>error</div>
  if (isValidating) return <div>loading</div>
  if (data) return <div>{data}</div>
}
  1. shouldComponentUpdate即使/api/account获取到数据也不会对当前组件进行刷新
  2. ["/api/assets", {id: assetsId}]是 useXS 的第一个参数，可以是string, array或者返回string或者array的函数；它最终会被作为fetcher的实参进行使用
  3. [account]表示的是依赖关系，也就是说assets中的url或者params使用到了account中的值；

Usage

const {data, error, isValidating, clearPooling, isPooling} = useXS(
  key,
  fetcher,
  config,
  deps
)

Return Value

data

  1. 如果有缓存数据的话，首先返回缓存数据
  2. 判断是否存在正在执行的请求；
    1. 如果请求正常返回，会在请求结束以后对 data 进行更新
    2. 如果不存在，判断当前的缓存数据是否可用
      1. 如果可用，处理结束
      2. 如果不可能，开始验证请求，并且等待请求结束进行数据更新

error

  1. 如果请求结束，并且报错的话
    1. 判断是否可以进行重试
      1. 如果可以重试，则重新发起请求，并且等待返回状态
      2. 如果说没有重试机会，则设置 error 为当前处理的错误信息

isValidating

请求发送开始，直到拿到结果或者说重试次数完成都被认为是is validating.

clearPooling

当存在轮询操作时，可以通过这个方法结束掉轮询处理

isPooling

如果说poolingInterval !== 0的话，排除第一次请求以及它会存在的重试；接下来的状态它一直为true

Params

key

唯一标识 fetcher 的字段，最好是url和params的组合；可以是string，array或者说返回string/array的函数。函数的场景一般是针对url或者params是一个runtime的值

fetcher

返回Promise的函数，一般情况就是指Ajax请求；字段key会给他提供一个(url)或者两个参数(url, params)

config

  1. staleWhileRevalidateMS=5 * 60 * 1000，指定 cache 过期以后，还能够使用的毫秒数
  2. poolingInterval=0, 轮询间隔毫秒数
  3. retryMaxCount=3，最多重试的次数
  4. retryInterval=1000，重试的基数时间间隔毫秒数
  5. forceValidate=false, 不验证缓存数据是否有效，每一次都会触发请求试图对缓存数据更新
  6. suppressUpdateIfEqual=true，当获取到数据以后，会进行新旧值的对比；默认情况下，如果说相等的话，依赖它的请求不会再触发
  7. shouldComponentUpdate，即使 data 发生变化也不触发组件的重新渲染，用来优化请求存在依赖关系时造成的无效渲染消耗
  8. onSuccess, 如果请求正常返回，则会直接被调用；如果报错，会在重发请求正常返回时进行调用
  9. onError, 如果请求失败，并且重试结束，依旧返回报错时进行调用

deps

指定当前请求存在的依赖关系，它的值需要是useXS返回的 result。使用时有下面的注意点

  1. 当存在依赖时，key需要是一个函数，否则直接使用undefined值会报错
  2. 因为渲染控制的约束，result 的解构只能发生在key函数中；否则如果deps设置了shouldComponentUpdate=false的话，在key函数中拿不到最新的值；

下面的例子存在的问题是，即使因为shouldComponentUpdate的设置，account发生了变化，即使xswr可以自动触发assets对应的函数调用，但是在keyFn中拿到的data依旧是旧值比如 undefined，然后就会报错。具体写法参考quick-start

function Account() {
  const account = useXS("/api/account", fetcher, {
    shouldComponentUpdate: false
  })

  const {data} = account

  const assets = useXS(
    () => {
      const {assetsId} = data
      return ["/api/assets", {id: assetsId}]
    },
    (url, params) => {
      return fetch(url, params)
    },
    [account]
  )

  const {data, error, isValidating} = assets

  if (error) return <div>error</div>
  if (isValidating) return <div>loading</div>
  if (data) return <div>{data}</div>
}

FAQ

与swr相比解决的问题和区别

相同点：

  1. 提供 cache，retry 和 pooling 在前端的一个易用性解决方案
  2. 可以搭配 React Hooks 使用，当数据更新时触发组件的渲染
  3. 当请求存在依赖时，提供解决依赖问题的方案

不同点：

  1. 在处理 deps 的方式上，为了准确的知道接口之间的依赖关系，从而实现对附属接口的调用，xswr 使用了类似useEffect中对依赖的书写方式

优点：

  1. 机制上的优化，config是隔离的，fetcher 只是一个数据提供方，当需要使用数据时，只需插到对应的 fetcher 上即可（此过程会存在触发数据验证的处理)。
  2. 渲染控制的优化，当接口之间存在数据依赖时，如果页面的展示只跟请求A的字段有关，那么它的所有依赖接口其实只是为了丰富请求A的请求数据，这些依赖接口如果触发了页面的重新渲染的话，其实就是对性能的浪费。

缺点：

  1. 对 suspense 的支持
  2. 对于 page 上比如视窗，滚动等优化处理
  3. 对网络状态的支持
  4. 对页面 prefetch 的支持