useRequest options.ready behavior

[brickspert]

这里我们来讨论下 3.0 useRequest options.ready 的行为。

为什么要加 ready 属性？

我理解 ready 最核心的诉求是以下两点：

1. 串行请求，当 ready 变为 true 时，才发起请求。

const { data } = useRequest(service1);
const { data: data2 } = useRequest(service2, {
    ready: !!data
});
const { data: data3 } = useRequest(service3, {
    ready: !!data2
});

比如上面的示例，通过 ready 实现了三个请求的串行。

2. 当 ready = false 时，阻止任何请求。

const { data, run } = useRequest(service2, {
    manual: true,   
    ready: false
});

<div onClick={run}>click</div>

在上面的示例中，当 ready 为 false 时，任何时候请求都是不会发出的。

目前存在哪些问题

但目前在 ready 的行为设计上，还是有很多地方有歧义：

当 manual=false 时的行为

1. ready 在每次从 false 变为 true 时都会自动发起请求吗？

这个我个人理解，确实应该每次变为 true 时发起请求。

2. defaultParams 在何时使用？

defaultParams 是在默认发起请求时带上的参数，那每次 ready 从 false 变为 true，参数行为应该是怎么样的？是都带？还是都不带？还是只有首次带。

3. ready 在自动请求时，是调用 refresh，还是 run？

假如我手动触发过 run(1, 2, 3)，那未来下一次 ready 从 false 变为 true 时，自动调用应该带上哪个参数？

4. ready=false 时，runAsync 的 Promise 是不会响应？还是 reject

这个我理解应该挂起不响应。

当 manual=true 时的行为

1. ready 开始是 false，然后手动调用了 run，此时应该不会发起请求。但当 ready 从 false 变为 true 时，会自动发起上次请求吗？

这个我理解应该是不会。

最后

回到加 ready 的初衷来讲：

1. 当 manual=true 时，如果 ready=false，则所有的 run 都是无效的。
2. 当 manual=false 时，每次 ready 从 false 变为 true，都会自动发起请求。但是 defaultParams 是不是每次都带上就是比较头疼的问题了。同时假如已经通过 run 触发过执行，那应该使用上一次的参数么。

[chj-damon]

我的理解：manual的意思就是手动，表示请求应该由调用方主动通过run方法触发，在触发时刻才去检查ready是否为true，如果为false，表示这一次手动触发的请求应该是无效的。所以，即便是ready为true，但只要没有调用run或者refresh，都不应该执行

[brickspert]

我的理解：manual的意思就是手动，表示请求应该由调用方主动通过run方法触发，在触发时刻才去检查ready是否为true，如果为false，表示这一次手动触发的请求应该是无效的。所以，即便是ready为true，但只要没有调用run或者refresh，都不应该执行

同意。

[we6288815]

我个人认为，当 manual=false 时，每次ready从false变为true，都将使用最新的defaultParams，而无需理会run的参数，只有refresh的时候，才使用run的参数或defaultParams

[brickspert]

我个人认为，当 manual=false 时，每次ready从false变为true，都将使用最新的defaultParams，而无需理会run的参数，只有refresh的时候，才使用run的参数或defaultParams

感觉这个可以有。似乎是一个正确的行为。

[p1scess]

串行或者并行是不是可以交给用户自己处理，封装了ready的话，可能用户也不一定想起来去用，而且封装了很全的功能话，不一定有一个小而精的功能来的实用，个人理解哈

[brickspert]

用户可以不用 ready，自行处理串行的。 ready 相当于一个语法糖~~

[zzzzyp]

个人理解：manual为true时是否发送请求应该完全交由用户控制，ready值此时应该失效掉

[hemengke1997]

在我的业务场景中，使用ready主要是：

1. 在组件初始化时通过ready控制是否请求
2. 在渲染过程中，根据ready判断是否请求，此时请求是由refreshDeps改变引起的

作者，我还有个问题，因为我目前正在重构项目，老项目用的 ahooks v2，如果现在重构到 v3 ，v3不支持ready，我该怎么做，以方便之后过渡到 v3 支持ready？

[brickspert]

根据上面讨论，目前确定 ready 行为为：

1. 当 manual=false 时，每次 ready 从 false 变为 true， 都会发起请求，默认带参数 defaultParams
2. 当 manual=true 时，ready 为 false 时，通过 run/runAsync 等触发不会发起请求。通过 runAsync 的 Promise 会挂起，不成功也不失败。

[brickspert]

已发布 v3.0.0-alpha.14

[alanwei0]

在最新的3.0.0版本里面，我同时设置了refreshDeps和ready，如下：

const { data: task, loading: loadingTask } = useRequest(
    () => getTask({ projectUrl: key, taskId }),
    {
      refreshDeps: [taskId, key],
      ready: key !== undefined && taskId !== undefined,
    }
);

key和taskId的变化过程如下：

1. key = 1, taskId = undefined.
2. key = 1, taskId = 222

理论上getTask应该只触发1次才对，然而实际上却触发了2次

[alanwei0]

是否可以在doc里详细描述下ready和refreshDeps的机制，主要是一起配置的话，之间的相互作用

[chj-damon]

按理说都是插件，不存在谁的权重高的问题。感觉是bug

[brickspert]

这种情况确实之前没有考虑到。

1. ready 从 false 变成 true 的时候，会调用 run(...defaultParams)
2. refreshDeps 变化时，会调用 refresh

所以会发起两次请求。

感觉应该是 ready 的行为高于 refreshDeps，我想想代码怎么改。

[brickspert]

v3.0.1 修好了

[alanwei0]

效率真高，感谢，可别引起别的bug呀，哈哈

[ihaichao]

有些场景下，使用 ready 校验请求参数，参数不完整的时候接口没有触发，可能会导致很难排查问题，这种场景如果不用 ready，发出请求，接口会报错参数缺失，会更容易排查问题，想看看大家是怎么看待这个问题

[bilibilikanpei]

这里设计ready做了两件事情：
1.校验参数合法性；
2.从不合法到合法则发请求；
感觉第2点不纯粹，必须从不合法到合法不太自然，如果只做第1点会更容易掌握。

[jaybowang]

ready从文档的介绍来看，确实和manual区别不大。或者说有其他具体场景文档没有提到？

对于串行请求，个人认为useSWR的方案会更好一些，那就是传入给第二个useRequest的参数是undefined即可，获取到第一个网络请求的数据后再设置为正常的值，就触发第二个请求。
类似于：

const { data: data1 } = useRequest(getData1);
const { data: data2 } = useRequest(data1 ? getData2 : undefined);