rephrasing and reorganising

README.md

@@ -11,10 +11,14 @@ redux-saga-rxjs
 
 # Work In Progress...
 
-## What is Saga pattern?
+## Introduction
+
+### Redux is great, side-effects are problematic
+
+### What is Saga pattern?
 Saga is a pattern for orchestrating long running transactions... TODO
 
-## Why is Saga good and probably mandatory for Redux?
+### Why is Saga good and probably mandatory for Redux?
 Redux is just predictable state container. We can say that all it does (and it does very well) is holding refrence of your application state and providing interface to mutate it (dispatching actions) in single transaction. Whenever any action (interaction with the UI) is dispatched, the reducer is called with provided application state and action to perform the mutation. The simplest model of Redux is State Machine because it defines two concepts: States and Transitions where in context of Redux - States are references to application state snapshot in specific time and Transitions are Actions.
 
 State Machine is missing one important piece and it's the transition history. State machine knows current state but it doesn't know anything about how it got to the state, it's missing **Sequence of transitions**. However, the Sequence of transitions is often very important information. Let's imagine you want to withdraw money from ATM, the first thing you need to do is enter your credit card and then enter the PIN. So the sequence of transitions could be as follows: `WAITING_FOR_CREDIT_CARD` -> `CARD_INSERTED` -> `AUTHORIZED` or `REJECTED` but we would like to allow user enter invalid PIN 3 times before rejecting.
@@ -67,7 +71,7 @@ const reducer = (appState, { type }) {
 }
 ```
 
-So why people keep saying that Saga is good for Side effects? Let's just take API call as a good example of side effect. When you want to call an API you probably want to have three actions `API_REQUESTED`, `API_SUCCEEDED`, `API_FAILED` and now you can imagine this as the **long running transaction** because it's a **sequence of actions which lives in time** (long running) and you need to connect the Request with Response (transaction).
+So why people say that Saga is a great pattern for Side effects? API call is a good example of side effect - you'll probably have one action (`API_REQUESTED`) dispatched when user clicks the button to load data which presumably display loading spinner and another action to process the response (`API_FINISHED`) and this is all in single long running transaction which Saga can handle.
 
 
 ## Usage