这周主要涉及了hooks的开发，有时感觉用的不是很到位，但是对于hooks与utils的区别有了更深入的了解，以及自己的看法。
1. hooks与utils的区别
- 以前常说，hooks和utils一个是有状态的函数，一个是纯函数（不会改变页面中的状态，也不需要提供状态供页面使用，有状态就与之相反了）。但现在我有了新的理解，其实所有可以用hooks的地方，我认为也都可以用utils来代替，只不过要搭配全局的状态管理store来实现。 因为hooks无非是两部分，一部分涉及提供状态供页面使用，这个可以用store来代替，另一部分涉及逻辑处理，这个可以用utils代替。所以姑且浅显地总结出一个公式hooks=utils+store。
- 但是存在即合理，hooks的优势到底在哪里？
- 当一个功能涉及多重逻辑时，通过使用hooks，可以让相关逻辑都集合在一起，使代码更清晰。
- 逻辑不复杂，但是不希望页面之间的状态互相影响。因为如果使用store意味着状态共享。
2. 使用hooks的具体场景
2-1. 某个操作会引起相关的一系列的逻辑处理
2-1-1. 提取扫码登录相关逻辑，封装成hooks。
- 需要提供的状态：qrcodeImgSrc（二维码图片）、qrcodeIsVisible（二维码图片是否可见）、scanResult（扫码结果）
- 相关逻辑处理：getCodeImg（获取二维码图片）、changeLongPollingStatusFlag（切换是否可以轮询状态）、longPoll（长轮询获取当前扫码的状态） 像这个例子中，要提供的状态和逻辑都不止一个，所以很适合放在一起，提取成一个hooks。
2-2. 操作不复杂，但复用性很高，且每个页面的状态尽量互不影响。
2-2-1. useToggle
不具体实现useToggle，它很简单，就是提供一个布尔状态，再提供一个方法去修改这个布尔状态。这是一个很常用的逻辑。虽然提供的状态不多，但是如果用utils+store来实现，一涉及store，肯定是全局的状态，它是公用的，页面之间会互相影响，所以也很适合用hooks来实现，这样每个页面之间的状态都是独立的。
3. 下面是这周遇到的一些问题
3.1 没有搞清楚响应式，到底是谁和谁之间建立了依赖关系。
- 其实应该是页面和变量之间建立了依赖关系，而不是变量和变量之间建立了依赖关系，建立变量之间的依赖关系应该通过computed九三属性。
// 定义hooks
export const useTest = (a: Ref<number>) => {
const t = ref(false)
if (a.value > 2) {
t.value = true
}
const change = () => {
t.value = true
}
return [t, change]
}
//页面使用这个hooks
const num1 = ref(0);//num1被双向绑定到了一个input框上。
const status = useTest(num1)
这样写之后，我以为status会随着页面上输入的num1的改变，而发生变化。事实是status根本不会有变化，因为我误以为hooks接受了一个响应式变量为参数，那么这个hooks就会自动随着输入变量的变化而发生变化。其实useTest只会在status初始化时执行一次，以后不管num1 怎么变化，useTest都不会再变化了。要想让num1的变化，引起status的变化，必须让status依赖num1，也就是通过computed计算属性来实现。
const status = computed(()=>useTest(num1).value)
3.2 误以为同一个hooks导出的状态test，在不同页面之间会共享，即a页面改变test状态后，b页面的test也会随着改。
- 有时候就是很奇怪，不知道为什么会想当然认为一些事情。可能还是对概念理解的不够透彻。
