Merge branch 'update_docs' of https://github.com/freeletics/FlowRedux …

…into update_docs

docs/dsl-cheatsheet.md

@@ -10,13 +10,13 @@ spec {
 
         // Handle external "input", called Actions
         on<Action1>{ action, state -> ... } //  Handle an action
-        on<Action2>(ExecutionPolicy){ action, state -> ... } //  You can have multiple on<Action> blocks. Optinal specify ExecutionPolicy
+        on<Action2>(ExecutionPolicy){ action, state -> ... } //  You can have multiple on<Action> blocks. Optionally specify ExecutionPolicy
 
         // Do something when you enter the state.
-        onEnter{ state -> ... } // called exactly one time when the given state has been entered
+        onEnter{ state -> ... } // Called exactly one time when the given state has been entered
         onEnter{ state -> ... } // You can have multiple onEnter blocks
 
-        // Collect a Flow (from coroutine package) as long as the state machine is in the state (see inState<State>)
+        // Collect a Flow (from kotlinx.coroutines) as long as the state machine is in the state (see inState<State>)
         collectWhileInstate(flow1) { valueEmitedFromFlow, state -> ... } // stops flow collection when state is left
         collectWhileInstate(flow2) { valueEmitedFromFlow, state -> ... } // You can have multiple collectWhileInstate
 
@@ -25,7 +25,7 @@ spec {
         onEnterEffect{ state -> ... } // You can have multiple onEnterEffect
         collectWhileInStateEffect(flow1){ valueEmitedFromFlow, state -> ... } // You can have multiple collectWhileInstate
 
-        // hierarchical state machines
+        // Hierarchical state machines
         onEnterStartStateMachine(
             stateMachineFactory = { stateSnapshot : State1  -> OtherStateMachine() },
             stateMapper = { state : State<State1>, otherStateMachineState : OtherState ->
@@ -45,9 +45,9 @@ spec {
         condition({state.someString == "Hello" }){
             // Everything inside this block only executes if the surounding condition is met 
             // and the state machine is in the state as specified by the top level inState<State1>.
-            // 
-            //  you can have multiple of the dsl blocks, i.e. multiple on<Action> blocks and so on.
-            on<Action3>{ action, state -> ... } // you can have multiple on<Action>
+
+            //  You can have each DSL block multiple times, i.e. multiple on<Action> blocks and so on.
+            on<Action3>{ action, state -> ... }
             onEnter{ state -> ... }
             collectWhileInState(flow){ valueEmitedFromFlow, state -> ... } 
             onActionEffect{ action, state -> ...}
@@ -74,7 +74,7 @@ spec {
                 // Please note that you cannot have a condition block inside an untilIdentityChanged block
             }
 
-            // Please note taht you cannot have nested conditions inside a condition block
+            // Please note that you cannot have nested conditions inside a condition block
         }
     }
 

docs/user-guide/11_ExecutionPolicy.md

@@ -36,7 +36,7 @@ There are three options to choose from:
     }
     ```
 
-    Let's assume that we trigger two times `BarAction`.
+    Let's assume that we trigger `BarAction` two times.
     We use random amount of seconds for waiting.
     Since we use `UNORDERED` as policy `on<BarAction>` the handler block gets executed 2 times without canceling the previous one (that is the difference  to `CANCEL_PREVIOUS`).
     Moreover, `UNORDERED` doesn't make any promise on order of execution of the block (see `ORDERED` if you need promises on order).

docs/user-guide/2_inState.md

@@ -17,7 +17,7 @@ class ItemListStateMachine(
 }
 ```
 
-`inState<Loading>` is just an "entry point".
+`inState<Loading>` is just an "entry point" that describes that anything inside this block should only be executed while the state machine is currently in a state that matches the given class.
 Next let's discuss what an `inState` block can contain as triggers to actually "do something":
 
 1. `onEnter`: Triggers whenever we enter that state

docs/user-guide/3_onEnter.md

@@ -45,4 +45,4 @@ Recall that FlowRedux is a multi-threaded asynchronous state machine. We will ta
 
 The key takeaway here is that with `onEnter { ... }` you can do some work whenever your state machine is entering this state and then move on to another state by calling `State.override()` or `State.mutate()`
 
-To be able to fully understand the code snipped from above, let's take a look at `State<T>` and `ChangedState<T>`.
+To be able to fully understand the code snippet from above, let's take a look at `State<T>` and `ChangedState<T>`.

docs/user-guide/5_onAction.md

@@ -43,7 +43,7 @@ class ItemListStateMachine(
 }
 ```
 
-A `on { ... }` block gets 2 parameters:  `action` which is the actual instance of the `Action` that triggered this block
+An `on { ... }` block gets 2 parameters:  `action` which is the actual instance of the `Action` that triggered this block
 and `state : State<T>` which gives us access to the current state and let us to state transitions with `.override()`.
 `on { ... }` is actually pretty similar to `onEnter {...}` just with a different "trigger" (action vs. entering a state)
 . Furthermore, `on { ... }` has the same characteristics as `onEnter { ... }`: