前言
咳，新公司每个月都需要有文章分享，之前已经写过两篇：源码流程速读、上手篇，但是写的比较随意，也没有加入一些自己思考，直接分享出去，多少有点low，故重新整理了一篇
注册流程
获取到vue实例
按照vue的插件注册流程，提供一个包含install函数的对象，vue将自动进行调用
向vue注入
通过provide和config.globalProperties向子孙组件挂载pinia实例
这虽然看着像是注入了两次，有点多余，但实际并不是，个人觉得是这样的：
对于provide来说，需要显示的定义inject（pinia已经帮我们做了这件事），而对于setup函数来说，是没有this环境的，故我们还需要手动引入inject并显示的接收pinia，但这是不可能的，因为pinia提供的provide是一个Symbol类型，伪代码如下
基于上一条原因，则可以认为globalProperties主要是为了能从组件实例上直接访问到pinia
定义模块store
defineStore
就是一个利用了高阶函数实现参数保留的方法
useStore
理论上这和直接从this上读取上一样的：
this.$pinia._s.get('stateName')
但是除了获取外，useStore还提供了新增state，以及一些公共api
这种在使用时再挂载的方式很值得学习，比如在写业务的时候，可以优先让ui界面展示出来，随后再将点击等事件通过某种实现附加到对应的操作元素上，而不是一股脑全部加载，这样对页面渲染速度以及用户体验上来说一定是有所提升的，虽然可能不多
createSetupStore和createOptionsStore
createOptionsStore最终指向的仍然是createSetupStore，只是在这里做了一层参数的转换处理
在createSetupStore中，首先创建一个空对象
接着设置其具体的值，即在组件中使用useFunc获取到的一套操作对象类
依赖收集
vue3给我们提供了effectScope允许我们控制依赖的生命周期：收集、销毁等，所以理论上我们只需要保证最顶层的对象是一个响应式的即可
我觉得，vue2是编译时的，因为它的state在定义时就已经被确定，它通过将state作为vue的data而走initState的一套逻辑递归的完成依赖收集。vue3则更像是运行时，它是动态的，仅在使用时才会被定义
那么如法炮制一下，只需要在执行子state模块时使用effectScope做一次收集可以，其中setup即使用option api或者setup api通过defineStore定义的代码
apis
$reset
首先，它是$patch的语法糖
其次，它只在options api中才有效
在setup中不可用的原因，应该是这样的：options api形式下，在提交给vue做处理前，给pinia留了操作空间（可以解构出state并做保留），而setup则是函数形式，是直接利用effectScope来收集ref/reactive等的
$patch
如果只是更新单个值的话，由于state中值已然是响应式的，故直接修改是可以正常触发页面re-reder的，而如果想要批量更新的话，在vuex中的做法则必须在mutions中定义函数并将要更新的内容传入
pinia提供的$patch允许我们直接进行批量更新，其实不读源码就能想到：由于vue中并不会接受到一个依赖变更就马上re-patch，而是会先存在队列中，故，对对象做遍历并依次更新是可行的
$subscribe
既然是订阅通知，则一定是要用到观察者或者发布订阅模式了
订阅
订阅行为的发生一定是在属性值发生改变之前的
这实际上是暂存callback与队列中
发布更新
既然是队列存储，则更新就只需要run一遍并依次回调即可
而触发通知时机即调用了$patch、$reset等时，如：
对于不走$patch做更新的，如state.name='spp'，则triggerSubscriptions是无法被触发的，在pinia中则针对这部分逻辑使用了watch做监听，这在调用$patch时会重复走两次（尽管源码注释的是手动调用时会停掉watch，但是在源码中没有调用watch销毁的地方，且打印也确实走了两次......）
mapState辅助函数
如下图框红所示，该函数内部会帮我们调用useStore并将值读取返回
这也就意味着我们无法像vuex那样，使用一个useState去解构出任意模块的state，不过我们可以手动写一个类似这样的函数来代替
插件
pinia提供use方法接受插件并存在列表中
由于pinia的模块状态是动态，故每当"新建"状态时都是需要run一遍插件保证插件拿到数据的完整性
