- 一开始在组件里自己写调用一个 api:dispatch('jia',2) ,传入一个 key 和一个参数 2
-
然后到了 Actions actions 为一个对象,调用 api:commit('jia',2)
-
然后到 mutation 里面 mutation 也是个对象里有着方法, 在对应方法里写, 一个方法, 这个方法里包含了 state 和那个传入的值, 只要在这个方法里写入 state.sum+=2 就相当于实现了 mutate 的操作。
-
然后到 state 里面,state 是一个对象,里面放着共享的变量,就把里面对应的数据给修改了。
-
最后重新进行组件的解析, 更新数据。
而这边的 actions 可以接受发送 Ajax 请求的返回值
而如果知道要进行操作的数据时, 即数据在组件中就可提供时, 可以跳过 actions 直接到 mutations
举例:
用一个去餐厅吃饭的例子来说明
组件相当于客人当你到了餐厅, 然后叫了服务员, 说了要点了蛋炒饭两份(蛋炒饭相当于数据类型, 2 相当于传的数据):dispath('jia',2)
然后服务员(actions)通过 app 帮你点菜, 填入的 · 内容也就是要两份蛋炒饭告知后厨需要两份蛋炒饭:commit(‘jia’,2)
然后后厨(mutations)知道了要两份蛋炒饭, 就进行制作 (相当于对我们的数据进行加工操作: state.sum+=2)
然后菜(state)就做完了就传(render)给客人吃
而如果客人跟后厨很熟的话, 也就不需要服务员, 直接和后厨说要吃什么菜后厨就做什么菜, 这就相当于省去了 actions
但是如果客人进店点餐, 发现菜都换过了, 那么此时必须需要服务员帮你点餐, 而这就相当于你这个数据是在另外一台 · 服务器上时, 要通过 actions 里发送 Ajax 请求获取到对应数据
而且服务员还可以当你点了两个菜而这两个菜刚好不能一起吃, 那么服务员也会提醒你, 就相当于进行等一等再相加, 当和为奇数时再相加一个道理, 有逻辑的判断就需要写在 actions 里。
而且这三个 actions mutations state 必须都要用一个 store 仓库进行管理
store 不可或缺, 因为掉这些 api 都需要 store
即 store.dispath,store.commit