[docs] update getters and actions

Author: yyx990803

docs/en/SUMMARY.md

@@ -5,7 +5,7 @@
 - [What is Vuex?](intro.md)
 - [Getting Started](getting-started.md)
 - Core Concepts
-  - [State](state.md)
+  - [State and Getters](state.md)
   - [Mutations](mutations.md)
   - [Actions](actions.md)
 - [Data Flow](data-flow.md)

docs/en/actions.md

@@ -59,7 +59,7 @@ import { incrementBy } from './actions'
 
 const vm = new Vue({
   vuex: {
-    state: { ... }, // state getters
+    getters: { ... }, // state getters
     actions: {
       incrementBy // ES6 object literal shorthand, bind using the same name
     }
@@ -93,7 +93,7 @@ import { incrementBy } from './actions'
 
 const vm = new Vue({
   vuex: {
-    state: { ... },
+    getters: { ... },
     actions: {
       plus: incrementBy // bind using a different name
     }
@@ -103,27 +103,31 @@ const vm = new Vue({
 
 Now the action will be bound as `vm.plus` instead of `vm.incrementBy`.
 
+### Inline Actions
+
 If an action is specific to a component, you can take the shortcut and just define it inline:
 
 ``` js
 const vm = new Vue({
   vuex: {
-    state: { ... },
+    getters: { ... },
     actions: {
       plus: ({ dispatch }) => dispatch('INCREMENT')
     }
   }
 })
 ```
 
-Finally, if you simply want to bind all the actions:
+### Binding All Actions
+
+If you simply want to bind all the shared actions:
 
 ``` js
 import * as actions from './actions'
 
 const vm = new Vue({
   vuex: {
-    state: { ... },
+    getters: { ... },
     actions // bind all actions
   }
 })

docs/en/data-flow.md

@@ -65,7 +65,7 @@ const app = new Vue({
   el: '#app',
   store,
   vuex: {
-    state: {
+    getters: {
       count: state => state.count
     },
     actions: {

docs/en/forms.md

@@ -16,7 +16,7 @@ The "Vuex way" to deal with it is binding the `<input>`'s value and call an acti
 ``` js
 // ...
 vuex: {
-  state: {
+  getters: {
     message: state => state.obj.message
   },
   actions: {

docs/en/state.md

@@ -1,4 +1,4 @@
-# State
+# State and Getters
 
 ### Single State Tree
 
@@ -48,7 +48,7 @@ However, this pattern causes the component to rely on the global store singleton
 
   By providing the `store` option to the root instance, the store will be injected into all child components of the root and will be available on them as `this.$store`. However it's quite rare that we will need to actually reference it.
 
-2. Inside child components, retrieve state with **getter** functions in the `vuex.state` option:
+2. Inside child components, retrieve state with **getter** functions in the `vuex.getters` option:
 
   ``` js
   // MyComponent.js
@@ -57,7 +57,7 @@ However, this pattern causes the component to rely on the global store singleton
     data () { ... },
     // this is where we retrieve state from the store
     vuex: {
-      state: {
+      getters: {
         // a state getter function, which will
         // bind `store.state.count` on the component as `this.count`
         count: function (state) {
@@ -74,19 +74,38 @@ However, this pattern causes the component to rely on the global store singleton
 
   ``` js
   vuex: {
-    state: {
+    getters: {
       count: state => state.count
     }
   }
   ```
 
+### Getters Must Be Pure
+
+All Vuex getters must be [pure functions](https://en.wikipedia.org/wiki/Pure_function) - they take the entire state tree in, and return some value solely based on that state. This makes them more testable, composable and efficient. It also means **you cannot rely on `this` inside getters**.
+
+If you do need access to `this`, for example to compute derived state based on the component's local state or props, you need to define separate, plain computed properties:
+
+``` js
+vuex: {
+  getters: {
+    currentId: state => state.currentId
+  }
+},
+computed: {
+  isCurrent () {
+    return this.id === this.currentId
+  }
+}
+```
+
 ### Getters Can Return Derived State
 
 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:
 
 ``` js
 vuex: {
-  state: {
+  getters: {
     filteredMessages: state => {
       return state.messages.filter(message => {
         return message.threadID === state.currentThreadID
@@ -98,11 +117,9 @@ vuex: {
 
 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.
 
-> 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).
-
 ### Sharing Getters Across Multiple Components
 
-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:
+As you can see, the `filteredMessages` getter may be useful inside multiple components. In that case, it's a good idea to share the same function between them:
 
 ``` js
 // getters.js
@@ -119,13 +136,17 @@ import { filteredMessages } from './getters'
 
 export default {
   vuex: {
-    state: {
+    getters: {
       filteredMessages
     }
   }
 }
 ```
 
+Because getters are pure, getters shared across multiple components are efficiently cached: when dependencies change, they only re-evaluate once for all components that uses them.
+
+> 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).
+
 ### Components Are Not Allowed to Directly Mutate State
 
 It's important to remember that **components should never directly mutate Vuex store state**. Because we want every state mutation to be explicit and trackable, all vuex store state mutations must be conducted inside the store's mutation handlers.