definePlugin的使用方式疑惑以及onBefore的作为前置判断的需求

[Colory]

vue-request/src/useRequest.ts

Line 13 in 11f2546

function useRequest<R, P extends unknown[] = any>(

谢谢大佬

definePlugin 已经有导出类型，但是没有看到预留参数接口去使用它。只在基础代码中有使用到。

我看到了代码中使用，但是没有预留参数接口
可不可以增加参数入口 方便添加一些附加功能。

因为业务中对分页请求的处理稍微要复杂点 想附加一些结构化导出到 usePagination中 ，现在实现的做法稍微复杂了点。如果有可以直接附加 自定义plugin 到其中就更好了

还有一个点很疑惑的是 插件中的onBefore 和 useRequest中的返回参数不一致

其实请求中需要前置判断的时候较多，当前useRequest的onBefore 缺少了前置判断中断请求的方式。
ready 会有自动请求的一个理解问题，较多使用者无法理解其中含义。
所以通常的处理是 改为 manual 然后另外的方法判断后再调用 runAsync 增加了方法逻辑。

期望的其实是可以在onBefore中类似plugin的返回 isBreak或者其他Error Promise.reject之类的中断
但是如果大改 onBefore 会影响之前的版本使用，所以如果开放了plugin自定义附加回调应该也能满足简化使用的方式

Originally posted by @Colory in #121 (comment)

[John60676]

definePlugin 已经有导出类型，但是没有看到预留参数接口去使用它。只在基础代码中有使用到。
我看到了代码中使用，但是没有预留参数接口
可不可以增加参数入口 方便添加一些附加功能。

这个确实遗漏了，在下一个版本会在 useRequest 添加上 plugins 这个参数

插件中的onBefore 和 useRequest中的返回参数不一致

这指的是类型不一样吗，因为插件的 hooks 与 useRequest 的 hooks 是不一样的，只是这两个 hooks 的名称一样而已

其实请求中需要前置判断的时候较多，当前useRequest的onBefore 缺少了前置判断中断请求的方式。
ready 会有自动请求的一个理解问题，较多使用者无法理解其中含义。
所以通常的处理是 改为 manual 然后另外的方法判断后再调用 runAsync 增加了方法逻辑。

这里我不是很理解，可以详细解释一下吗

[Colory]

当前遇到的前置判断主要是

例如 有一个详细信息 在修改或者查看的时候 会调取 A 接口 参数是ID
形如// /path/{id}

写法上就有多种处理

// 数据声明
const userId = ref() // 默认是空
const req = (id) => Promise.resolve({}) // 模拟查询

// 手动传参
const { data, runAsync } = useRequest(id => req(id), { manual: true })
// 调用
const queryUser = () => !!userId.value && runAsync(userId.value)

// 或者
const { data, runAsync: queryUser } = useRequest(()=> req(userId.value), { ready: computed(() => !!userId.value) })


// 或者合并
const { data, runAsync: queryUser } =  useRequest(async ()=> userId.value? await req(userId.value) : undefined, { manual: true })

第一种方式偏向于手动，更好理解是userId存在 查询用户
第二种方式偏向于自动, userId存在 自动就请求了。重复换着查询就尴尬了。还是得调用 run 方法

// 我看了 其他库的通用处理也是 ready状态切换自动请求。但是这个对初用该库的人来说有点理解困难。🤣 🤣 🤣
// 而且更多的时候 ready 应该是作为依赖请求使用的。而不是前置判断。
//

期望的方式

const { data, runAsync: queryUser } =  useRequest(()=> req(userId.value), { manual: true, onBefore: () => /* 直接ID为空 中断请求  算作成功或者失败 */ !!userId.value })

const { data } =  useRequest(()=> req(userId.value), {  onBefore: () => /* 直接ID为空 中断请求  算作成功或者失败 */ !!userId.value， refreshDeps: /* id 变化自动请求 */ [userId] })

这种方式对大家的理解更OK 直观明确 查询请求的前置判断是 ID 不能为空。调用方法也是查询。
当然主要是为了简化代码 简化第一种场景下的查询 代码逻辑聚拢。
🤔 🤔 🤔

[John60676]

https://www.attojs.com/guide/documentation/refreshDeps.html#refreshdepsaction

这个可能对你有帮助

onBefore 本质上是一个 vue-request 的生命周期 ，它不应该干预运行的流程，就像是 vue 的 生命周期一样

[Colory]

https://www.attojs.com/guide/documentation/refreshDeps.html#refreshdepsaction

这个可能对你有帮助

onBefore 本质上是一个 vue-request 的生命周期 ，它不应该干预运行的流程，就像是 vue 的 生命周期一样

这种方式我也处理过，但是呢，代码可能会显得撕裂。
所以我是在想能否在 definePlugin中自己去扩展。实现一个可以干预 流程的onBefore 或者 其他 onXXXPre 之类的生命周期。
😄 😄😄

类似的就是beforeRouteEnter 阻止 路由跳转进入

defineOptions({
  beforeRouteEnter: (to, from, next) => {
    /* not ok, stop router next operation by throw error */
  }
});

[wyh369352887]

definePlugin 已经有导出类型，但是没有看到预留参数接口去使用它。只在基础代码中有使用到。
我看到了代码中使用，但是没有预留参数接口
可不可以增加参数入口 方便添加一些附加功能。

这个确实遗漏了，在下一个版本会在 useRequest 添加上 plugins 这个参数

插件中的onBefore 和 useRequest中的返回参数不一致

这指的是类型不一样吗，因为插件的 hooks 与 useRequest 的 hooks 是不一样的，只是这两个 hooks 的名称一样而已

其实请求中需要前置判断的时候较多，当前useRequest的onBefore 缺少了前置判断中断请求的方式。
ready 会有自动请求的一个理解问题，较多使用者无法理解其中含义。
所以通常的处理是 改为 manual 然后另外的方法判断后再调用 runAsync 增加了方法逻辑。

这里我不是很理解，可以详细解释一下吗

老哥，plugins啥时候加啊

[John60676]

plugins 已经在 2.0.4 版本加入

[Colory]

plugins 已经在 2.0.4 版本加入

大佬, 好像 usePagination 没有添加插件。usePaigination 可以添加插件吗？

[John60676]

usePaigination 和 useLoadmore 都是 useRequest 的二次封装，目前还没有计划给这两个添加上插件的功能，需要考虑一下开放插件功能会不会对原本的功能造成影响