VueHooks Plus 中 useFetchs 返回值的 Readonly 问题解析

在 VueHooks Plus 项目中，开发者在使用 useFetchs 和 useRequest 这两个 API 时可能会遇到一个关于返回值类型的差异问题。这个问题涉及到 TypeScript 中的 Readonly 和 DeepReadonly 类型修饰符的使用。

问题背景

useFetchs 和 useRequest 都是 VueHooks Plus 提供的用于数据请求的钩子函数，但它们在返回值的类型处理上存在不一致性：

• useFetchs 返回的数据使用了 DeepReadonly 修饰符
• useRequest 则只在最外层使用了 Readonly 修饰符

这种不一致性会导致开发者在将返回值赋值给其他变量时可能遇到类型不匹配的问题，特别是当目标变量没有被声明为 readonly 时。

技术分析

Readonly 与 DeepReadonly 的区别

在 TypeScript 中：

• Readonly 只对对象的第一层属性进行只读限制
• DeepReadonly 则会递归地对对象的所有嵌套属性都应用只读限制

问题影响

这种类型不一致会导致以下问题：

1. 类型兼容性问题：当开发者尝试将 useFetchs 返回的 DeepReadonly 数据赋值给普通类型变量时，会触发类型错误
2. 代码冗余：开发者需要手动处理类型转换，增加了不必要的代码量
3. 预期不一致：相似的 API 却有不同的类型行为，增加了学习成本

解决方案

项目维护团队在 v1.9.0 版本中已经修复了这个问题。主要改动是统一了 useFetchs 和 useRequest 的类型处理方式，使其行为更加一致。

最佳实践

对于开发者而言，在处理这类数据时可以考虑以下建议：

1. 如果确实需要修改返回的数据，可以先进行深拷贝再使用
2. 在大多数情况下，请求返回的数据应该被视为不可变的
3. 更新到最新版本以获得一致的类型体验

总结

这个问题的修复体现了 VueHooks Plus 团队对 API 一致性的重视。通过统一类型处理方式，减少了开发者的认知负担和潜在的类型错误。这也提醒我们，在设计类似的钩子函数时，保持 API 行为的一致性对于开发者体验至关重要。