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
Copy file name to clipboardExpand all lines: docs/en/data-flow.md
+34-37Lines changed: 34 additions & 37 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,27 +2,21 @@
2
2
3
3
Let's build a simple counter app with Vuex to get a better understanding of the data flow inside Vuex apps. Note this is a trivial example solely for the purpose of explaining the concepts - in practice you don't need Vuex for such simple tasks.
@@ -67,26 +56,34 @@ export default new Vuex.Store({
67
56
**Script**
68
57
69
58
```js
70
-
importstorefrom'./store.js'
71
-
72
-
exportdefault {
73
-
computed: {
74
-
// bind to state using computed properties
75
-
count () {
76
-
returnstore.state.count
59
+
// We are importing and injecting the store here because
60
+
// this is the root. In larger apps you only do this once.
61
+
importstorefrom'./store'
62
+
import { increment, decrement } from'./actions'
63
+
64
+
constapp=newVue({
65
+
el:'#app',
66
+
store,
67
+
vuex: {
68
+
state: {
69
+
count:state=>state.count
70
+
},
71
+
actions: {
72
+
increment,
73
+
decrement
77
74
}
78
-
},
79
-
methods: {
80
-
increment:store.actions.increment,
81
-
decrement:store.actions.decrement
82
75
}
83
-
}
76
+
})
84
77
```
85
78
86
79
Here you will notice the component itself is extremely simple: it simply displays some state from the Vuex store (not even owning its own data), and calls some store actions on user input events.
87
80
88
81
You will also notice the data flow is unidirectional, as it should be in Flux:
89
82
83
+
1. User input in the component triggers action calls;
84
+
2. Actions dispatch mutations that change the state;
85
+
3. Changes in state flow from the store back into the component via getters.
Copy file name to clipboardExpand all lines: docs/en/state.md
+6-6Lines changed: 6 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -21,7 +21,7 @@ computed: {
21
21
22
22
Whenever `store.state.count` changes, it will cause the computed property to re-evaluate, and trigger associated DOM updates.
23
23
24
-
However, this pattern causes the component to rely on the global store singleton. This makes it harder to test the component, and also makes it difficult to run multiple instances of the app using the same set of components. Ideally, we want to "inject" the store into child components from the root component. Here's how to do it:
24
+
However, this pattern causes the component to rely on the global store singleton. This makes it harder to test the component, and also makes it difficult to run multiple instances of the app using the same set of components. In large applications, we may want to "inject" the store into child components from the root component. Here's how to do it:
25
25
26
26
1. Install Vuex and connect your root component to the store:
27
27
@@ -82,7 +82,7 @@ However, this pattern causes the component to rely on the global store singleton
82
82
83
83
### Getters Can Return Derived State
84
84
85
-
Vuex state getters are computed properties under the hood, this means you can leverage them to reactively (and efficiently) compute derived state. For example, say in the state we have an array of `messages` containing all message, and a `currentThreadID` representing a thread that is currently being viewed by the user. What we want to display to the user is a filtered list of messages that belong to the current thread:
85
+
Vuex state getters are computed properties under the hood, this means you can leverage them to reactively (and efficiently) compute derived state. For example, say in the state we have an array of `messages` containing all messages, and a `currentThreadID` representing a thread that is currently being viewed by the user. What we want to display to the user is a filtered list of messages that belong to the current thread:
86
86
87
87
```js
88
88
vuex: {
@@ -96,13 +96,13 @@ vuex: {
96
96
}
97
97
```
98
98
99
-
Because Vue.js computed properties are automatically cached (and only validated when a reactive dependency changes), you don't need to worry about this function being called on every mutation.
99
+
Because Vue.js computed properties are automatically cached and only re-evaluated when a reactive dependency changes, you don't need to worry about this function being called on every mutation.
100
100
101
-
> Flux reference: Vuex getters can be roughly compared to [`mapStateToProps`](https://github.com/rackt/react-redux/blob/master/docs/api.md#connectmapstatetoprops-mapdispatchtoprops-mergeprops-options) in Redux. However, this leverages Vue's computed properties memoization under the hood, thus is more efficient than `mapStateToProps`, and more similar to [reselect](https://github.com/reactjs/reselect) and [NuclearJS getters](https://optimizely.github.io/nuclear-js/docs/04-getters.html).
101
+
> Flux reference: Vuex getters can be roughly compared to [`mapStateToProps`](https://github.com/rackt/react-redux/blob/master/docs/api.md#connectmapstatetoprops-mapdispatchtoprops-mergeprops-options) in Redux. However, because they leverage Vue's computed properties memoization under the hood, they are more efficient than `mapStateToProps`, and more similar to [reselect](https://github.com/reactjs/reselect).
102
102
103
103
### Sharing Getters Across Multiple Components
104
104
105
-
As you can see, in most cases getters are just pure functions: they take the whole state in, and returns some value. The `filteredMessages` getter may be useful inside multiple components, and it's totally possible to just share the same function between them:
105
+
As you can see, in most cases getters are just pure functions: they take the whole state in, and returns some value. The `filteredMessages` getter may be useful inside multiple components. In that case, it's a good idea to share the same function between them:
106
106
107
107
```js
108
108
// getters.js
@@ -132,4 +132,4 @@ It's important to remember that **components should never directly mutate Vuex s
132
132
133
133
To help enforce this rule, when in [Strict Mode](strict.md), if a store's state is mutated outside of its mutation handlers, Vuex will throw an error.
134
134
135
-
With this rule in place, our Vue components now hold a lot less responsibility: they are bound to Vuex store state via read-only getters, and the only way for them to affect the state is by somehow triggering **mutations** (which we will discuss later). They can still possess and operate on their local state if necessary, but we no longer put any data-fetching or global-state-mutating logic inside individual components.
135
+
With this rule in place, our Vue components now hold a lot less responsibility: they are bound to Vuex store state via read-only getters, and the only way for them to affect the state is by somehow triggering **mutations** (which we will discuss later). They can still possess and operate on their local state if necessary, but we no longer put any data-fetching or global-state-mutating logic inside individual components. They are now centralized and handled inside Vuex related files, which makes large applications easier to understand and maintain.
0 commit comments