Naming convention for selectors, note on action creators

Author: uanders

article/react-redux-concept-workflow.md

@@ -2,7 +2,7 @@
 
 Ulrich Anders
 
-Version 1.0.6, March 2017
+Version 1.0.7, March 2017
 
 ## Introduction
 
@@ -185,15 +185,15 @@ I'd like to start with a graphical cheat sheet explaining the workflow in a Reac
 
 1. Whenever the state in the store is updated, all your *mapStateToProps()* mapping functions for connecting components will be called and the new state data mapped to the properties of the connected components.
     
-1. If you only want to map a subset of your slice to certain properties in your component you can make a selection from the slice of your state tree. A function that makes a selection is called a *selector*. But remember each time the store gets an update all mapping functions are called independent of whether the state change is relevant for a component. That means that also all the selector functions are called. If a selector function now is computationally expensive, it might slow down your app. In this case you should optimize your selectors by help of ['reselect'](https://github.com/reactjs/reselect).
+1. If you only want to map a subset of your slice to certain properties in your component you can make a selection from the slice of your state tree. A function that makes a selection is called a *selector*. It is a convention to name selector functions with an initial *get...*. But remember each time the store gets an update all mapping functions are called independent of whether the state change is relevant for a component. That means that also all the selector functions are called. If a selector function now is computationally expensive, it might slow down your app. In this case you should optimize your selectors by help of ['reselect'](https://github.com/reactjs/reselect).
 
     ```JavaScript
     function mapStateToProps(state) {
       return {
         // component gets this.props.selection1
-        selection1: selector1(state.slice01),
+        selection1: getSelection1(state.slice01),
         // component gets this.props.selection2   
-        selection2: selector2(state.slice01)
+        selection2: getSelection2(state.slice01)
       }
     }
     ```
@@ -233,7 +233,7 @@ I'd like to start with a graphical cheat sheet explaining the workflow in a Reac
                            mapDispatchToProps)(SmartComponent01)
     ```
 
-1. Your component now has a *dispatch()* function. But what is the *dispatch()* function dispatching? A dispatcher normally dispatches a command to someone. Think of 911, where the dispatcher commands a police officer to undertake something. Or in a shop, where the dispatcher commands a good to be send to a customer. In Redux you need different commands, but they all relate to updating the state in the store. Each command therefore needs to contain two kinds of information. A type to represent the command and the data relevant for the state change. This command is called an [*action*](http://redux.js.org/docs/basics/Actions.html) in Redux. The name *action* may be confusing at first, since with this name one would rather expect a function than an object. However, with time you get used to it. The *action* is a plain JS object containing a type and ideally the minimal amount of *relevant* data required to perform the state change. 
+1. Your component now has a *dispatch()* function. But what is the *dispatch()* function dispatching? A dispatcher normally dispatches a command to someone. Think of 911, where the dispatcher commands a police officer to undertake something. Or in a shop, where the dispatcher commands a good to be send to a customer. In Redux you need different commands, but they all relate to updating the state in the store. Each command therefore needs to contain two kinds of information. A type to represent the command and the data relevant for the state change. This command is called an [*action*](http://redux.js.org/docs/basics/Actions.html) in Redux. The name *action* may be confusing at first, since with this name one would rather expect a function than an object. However, with time you get used to it. The *action* is a plain JS object containing a type and ideally the minimal amount of *relevant* data required to perform the state change.
 
 
     ```JavaScript
@@ -294,6 +294,8 @@ I'd like to start with a graphical cheat sheet explaining the workflow in a Reac
 
 1. In this way, the store receives a new state. When the store is updated with a new state state a re-render of the components that have subscribed to the store is triggered.
 
+1. Note, action creators are often used to create actions that lead to a change if the state in the store. But no all actions are used generate state changes. Some action objects may simply be generated by action creators to make temporary state changes to the app that are not stored.
+
 1. An arbitrary number of functions can register at the store to be also triggered whenever the store got updated with a new state. The functions registered at the store to be triggered have been named listeners, probably because they are "listening" to updates of the state. But in fact, they are not actively listening themselves. Quite the opposite, they are not actively in control, they are just passively triggered. The triggering function is a method that belongs to the store named [*store.subscribe()*](http://redux.js.org/docs/api/Store.html#subscribe). This name also takes a little bit getting used to as the store itself actually does not subscribe to anything. So, mentally you could think *trigger* when you use *subscribe()*.^[Don't confuse a component actually *subscribing* to a state change by help of the *connect()* function with a function that can be registered with the *store.subscribe()* method in order to be triggered whenever there is a new state.]
 
     ```JavaScript