You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is how we previously wrote Vuex Modules. Some of the obvious difficulties with this approach are:
54
39
55
-
* Lack of Type Safety: Type Safety and Intellisense when defining the store.
56
-
* Also notice how we are redefining **occupation** and **specialty** fields both as states and getters. This repitition and can easily lead to bugs if we update one and forget to update the other
57
-
* We also don't have any type secure way to use this module in our Vue components. We have to use strings to handle getters, commits and dispatch calls. This can easily lead to bugs.
58
-
59
-
A better approach to solving this problem would be to use a VuexModule class as follows.
This is a significant improvement over our initial method. First we get type safety out of the box since we're using classes without doing much work. Also note that **occupation** and **specialty** don't need to be redefined as getters any longer. Just import the getter decorator, use it on an already defined state and it automatically becomes a getter. This is useful when you have a long list of initialized state you also want to make available as getters. Which is also why state that are not getters must be **private**\
98
-
\
99
-
This module can now be used in our Vuex store by extracting it like so.
100
-
```ts
85
+
101
86
// store.vuex.ts
102
87
exportconst store =newVuex.Store({
103
88
modules: {
104
-
/**
105
-
* PLEASE NOTE
106
-
* ---------------------
107
-
* If you're using namespaces in your modules, then the modules object field
108
-
* must be the same value as your "namespacedPath" value.
109
-
* In this case, the "user" field must be the same as the namespacedPath "user/"
110
-
*
111
-
* If you're not using namespaces, this doesn't matter.
112
-
*/
113
-
user: UserStore.ExtractVuexModule( UserStore ),
89
+
...extractVuexModule( UserStore )
114
90
}
115
91
})
92
+
93
+
// Creating proxies.
94
+
const vxm = {
95
+
user: createProxy( UserStore ),
96
+
}
116
97
```
117
98
118
-
## Ok. So What About Vue Components?
119
-
Ensuring type safety in Vuex Modules is just one half of the problem solved. We still need to use them in our Vue Components.\
120
-
\
121
-
To do this is we just create a proxy in our Vue Component.
99
+
On the surface, it looks like not much has changed. But some rethinking has gone into how the libary works to make for a much better developer experience.
100
+
101
+
## More Powerful Proxies
102
+
With the `strict` option set to `false` we can enable greater functionality for our proxies with automatic getters and setters for our state.\
103
+
For Example:
122
104
```ts
123
-
@Component
124
-
exportclassMyComponentextendsVue {
125
-
126
-
user =UserStore.CreateProxy( this.$store, UserStore );
Notice that we didn't have to define a mutation to change the `firstname` we just set the state and it updates reactively. This means no more boilerplate mutations for our state, we just mutate them directly.
117
+
118
+
This also opens up new possibilities in how we consume stores in Vue components.
No more getters, commits or dispatch calls using strings. We just call them like we defined them in our class.
145
+
Notice how much boilerplate has been reduced both in defining our vuex stores and also in using them in our components.
146
+
Also notice we no longer need functions like `mapState` or `mapGetters`.
140
147
141
-
### We can do better
142
-
All is looking good. we've ensured type safety in our Vue Components by creating proxies that rely on the store object and then just calling the methods like normal.\
143
-
\
144
-
The only problem here is, in reality we might have one component making request to multiple vuex modules. Imagine a vue component talking to 5 vuex modules. Importing and creating proxies for each module in all our components might become repetitive and frankly unecessary.
148
+
## Implementing More Vuex Functionality
149
+
Vuex today has additional functionalities like `$watch``$subscribe` and `$subScribeAction` respectfully.
145
150
146
-
### Vuex Manager
147
-
A vuex manager is simply an exportable object that houses all your proxies. We can easily create a vuex manager in our original vuex store file. (See Example)
Vuex Actions comes in two modes. A `mutate` mode and a `raw` mode. Both can be very useful.\
224
-
For most of your use cases the `mutate` mode is all you'll need. The `raw` mode can be especially useful when you need access to `rootState` and `rootGetters`.\
The above code snippet highlights the difference between the two action modes.
265
-
266
-
Mutated Actions can access state, getters, mutations and other actions with the `this` keyword just like any normal function.
267
-
268
-
Raw Actions on the other hand gives you access to `rootState` and `rootGetters`. The only limitation to this appoach however is that **you can't and shouldn't use the `this` keyword.** Instead you should get back the context object with the `getRawActionContext` function and then treat the function body like a regular vuex action.
269
-
270
-
All actions MUST return a promise.\
271
-
All actions proxies are totally type safe and can still be used normally in Vue components whether mutatated or raw.
0 commit comments