|
@@ -15,7 +15,10 @@ At the center of every Vuex application is the **store**. A "store" is basically
|
|
After [installing](../installation.md) Vuex, let's create a store. It is pretty straightforward - just provide an initial state object, and some mutations:
|
|
After [installing](../installation.md) Vuex, let's create a store. It is pretty straightforward - just provide an initial state object, and some mutations:
|
|
|
|
|
|
``` js
|
|
``` js
|
|
-// Make sure to call Vue.use(Vuex) first if using a module system
|
|
|
|
|
|
+import Vue from 'vue'
|
|
|
|
+import Vuex from 'vuex'
|
|
|
|
+
|
|
|
|
+Vue.use(Vuex)
|
|
|
|
|
|
const store = new Vuex.Store({
|
|
const store = new Vuex.Store({
|
|
state: {
|
|
state: {
|
|
@@ -37,6 +40,37 @@ store.commit('increment')
|
|
console.log(store.state.count) // -> 1
|
|
console.log(store.state.count) // -> 1
|
|
```
|
|
```
|
|
|
|
|
|
|
|
+In order to have an access to `this.$store` property in your Vue components, you need to provide the created store to Vue instance. Vuex has a mechanism to "inject" the store into all child components from the root component with the `store` option:
|
|
|
|
+
|
|
|
|
+``` js
|
|
|
|
+new Vue({
|
|
|
|
+ el: '#app',
|
|
|
|
+ store: store,
|
|
|
|
+})
|
|
|
|
+```
|
|
|
|
+
|
|
|
|
+:::tip
|
|
|
|
+If you're using ES6, you can also go for ES6 object property shorthand notation (it's used when object key has the same name as the variable passed-in as a property):
|
|
|
|
+
|
|
|
|
+```js
|
|
|
|
+new Vue({
|
|
|
|
+ el: '#app',
|
|
|
|
+ store
|
|
|
|
+})
|
|
|
|
+```
|
|
|
|
+:::
|
|
|
|
+
|
|
|
|
+Now we can commit a mutation from component's method:
|
|
|
|
+
|
|
|
|
+``` js
|
|
|
|
+methods: {
|
|
|
|
+ increment() {
|
|
|
|
+ this.$store.commit('increment')
|
|
|
|
+ console.log(this.$store.state.count)
|
|
|
|
+ }
|
|
|
|
+}
|
|
|
|
+```
|
|
|
|
+
|
|
Again, the reason we are committing a mutation instead of changing `store.state.count` directly, is because we want to explicitly track it. This simple convention makes your intention more explicit, so that you can reason about state changes in your app better when reading the code. In addition, this gives us the opportunity to implement tools that can log every mutation, take state snapshots, or even perform time travel debugging.
|
|
Again, the reason we are committing a mutation instead of changing `store.state.count` directly, is because we want to explicitly track it. This simple convention makes your intention more explicit, so that you can reason about state changes in your app better when reading the code. In addition, this gives us the opportunity to implement tools that can log every mutation, take state snapshots, or even perform time travel debugging.
|
|
|
|
|
|
Using store state in a component simply involves returning the state within a computed property, because the store state is reactive. Triggering changes simply means committing mutations in component methods.
|
|
Using store state in a component simply involves returning the state within a computed property, because the store state is reactive. Triggering changes simply means committing mutations in component methods.
|