vue3+ts+vite的项目代码解读

解读目的

为了掌握并熟悉ts在实际项目中的运用方式和案例。

从main.ts开始的解读

下图中代码中比较重点的地方就是引入的store文件了

store文件

基本信息

store文件，vue3官网文档里对store文件有如下解释：
是一个解决多个组件依赖于同一个状态的状态管理方案
使用案例

接下里我们看看项目中store.ts的代码
先看引入
1.引入的createStore是Vuex4(用于Vue3)中创建store实例的函数。
后面的几个暂且不看，我们先去看后面的代码
这段代码大家应该很轻易的能看出她的一个结构，创建了一个包含了五个字段的接口，并且对每个字段都传入了一个对象，那这五个对象是从哪里来的呢，我们回到上面没有讲述的import来看，就是从那里来的
因为这几个对象来自不同的文件，要逐个去解析代码会花费较多时间，因此我们还是回到这个store/index.ts文件里接着往下看。

上面这段代码解读：
首先创建并暴露了一个叫AppStore的类型名称，并且为其设置了泛型，若在使用AppStore时未明确标注泛型，则以AppState作为其泛型值

// 注意接口和类型是两个具有相似作用的东西，二者都是用于定义数据的结构，二者的一些具体区别我放在下图了

接下来我们看下面图中红框内的代码

有点多，所以我们拆分来看

上图红框中的代码，用type创建了一个叫做Store的类型别名，用于进行类型检查，并且对该类型别名设置了一个泛型默认为AppState的泛型

这个类型别名的值是使用了工具函数Omit 从VuexStore(vue从vuex库导入的类型别名,前面的import代码中有从vuex中引入Store并取别名为VuexStore的)去除了getters,commit,dispatch属性的结果。

而既然vuex中已经有了状态管理的类型了，那我们为什么还要去把这个类型进行一个属性剔除，而不是直接拿来用呢？
这是因为getters,commit,dispatch这几个属性对应的函数的传入参数值和返回参数值的类型都是不确定的，因此我们需要自己重新构建一个传入参数值和返回参数值的类型是确定的getters,commit,dispatch.

接下来我们看剩余部分的代码

上图红框中的代码，通过type类型别名的语法——声明合并
使用&将新的类型与前面剔除了getters,commit,dispatch后的类型别名进行了一个合并。
我们具体来看看这新合并的两个类型别名：commit和dispatch，很明显是用来代替之前被omit工具函数剔除掉的commit和dispatch方法的。
用于合并的commit：
这个commit是个方法吗？我没看懂，所以先看看vuex中的store的原版commit长什么样子
如下所示：
参数1——type 要调用的 mutation 函数的名称，
参数2——pyload为传递给 mutation 的数据，

回到项目代码，我们不是要用新的commit方法去合并到新的VuexStore上吗，

以上代码为commit方法添加了类型变量K,K帮我们捕获用户传入的参数类型，并且我们还对这个K做了另外的要求，就是 extends keyof Mutations:
获取到Mutations对象的所有属性名称（keyof Mutations），并且将之作为K的泛型约束(extends,这个会要求用户传入的参数类型必须是我们要求的从Mutations中取得的所有字段的名称)

这里使用泛型约束的目的是为了能够在开发阶段代码编译前时就能够提前发现错误，从而精准的定位错误发生的位置，而不适用泛型约束的话，我们可能会在代码顺利编译后，在运行时，运行到使用这个方法的这一步时会出错，到那个时候再去找出错代码的位置在哪的难度也会变得十分大。以下是我对于ai的提问和它的解答
接下来对于下面红框中的代码解释也是一致的

看懂上图代码需要先知道的知识

1.Parameters

2.元组

以上代码为commit方法添加了泛型参数P ,P帮我们捕获用户传入的参数类型，并且我们还对这个P做了另外的要求：就是使用TypeScript的一个内置工具类型，获取到Mutations[K]（Mutations：对象，K：键值，Mutations[K]对应的是不同K值下的不同方法）对应方法的参数类型（并且以元组（固定场地，固定顺序，每个位置类型固定的元素集合）的形式返回，）的元组，然后拿到元组[1]的参数类型，将其作为P的泛型约束

接下来我们看下图红框中代码

上图红框中代码的解释：
: ReturnType<Mutations[K]>
这表示的是该函数的返回值类型，它会自动推断出对应 mutation 函数的返回类型（就是和你使用commit函数时传入的参数2——要传递给mutation的数据）


ok,这里我们对于这段代码也就看完了，这里我们进行一个总结：
首先我们重写commit，getters,dispatch的原因是：
这是因为getters,commit,dispatch这几个属性对应的函数的传入参数值和返回参数值的类型都是不确定的，因此我们需要自己重新构建一个传入参数值和返回参数值的类型是确定的getters,commit,dispatch.
然后我们就通过typescript 声明了一个具体函数，并且直接通过extends(泛型约束)对传入该函数的第一个参数和第二个参数进行了泛型约束，第一个约束的类型直接表明了参数1了必须是原来vuex的store中的mutations的方法名（string），第二个约束的类型直接表明了参数2必须是vuex的mutations的方法的第二个参数类型。

同理，下面的dispatch也是一样的操作，这里暂时就不多讲了。

ok，接下来我们去看下我们自己重写vuex的store的这个AppStore通过export后在哪里被用到了，
在store\index.ts中被用到了(现在你要知道我们重写的这个store就是一个和原来vuex的store具有相同的功能并且更完善的store)。

ok，到这里似乎store方面的内容似乎就完结了，但这里我要说一点，这点可能会有些突兀，因为这是我在写前面这些内容时一直没提出来的，那就是关于store这个文件夹的一个整体结构的解释，
我们能看到store下有一个index.ts和一个modules文件夹，很明显这个index.ts就是这个store文件夹的一个起始文件，或者说一个总体文件。

而modules文件夹下有多个文件夹，我们刚刚分析的app/index.ts文件夹就是其中app文件夹下的ts文件，我们打开app文件夹一看，能清晰看到里面还有其他几个ts文件，并且文件名一眼能看出来就是对于store的里mutations，actions,state的一个拆分，然后集合在app这个文件夹里，用于专门管理app这个模块相关的数据。然后在index.ts里暴露出来我们设计好的AppStore(store),再在store/index.ts里将各个模块store类型组合起来一起暴露出去，再在main.ts里使用app.use来完成多个不同store模块的创建并挂载使用

到这里你可能还会有疑问，那就是你可能没有用过这种拆分多模块和文件的store写法，可能也没有那种直接写一个store模块文件然后直接放在app.use()上挂载的经验，那么现在，就现在，你应该先去掌握一下单个store模块文件的写法。