Docs WIP

docs/Coeffects.md

@@ -32,7 +32,7 @@ to perform its computation.
 
 Because the majority of event handlers only need `db` and 
 `event`, there's a specific registration function, called `reg-event-db`, 
-which delivers these two coeffects as arguments to an event 
+which delivers ONLY these two coeffects as arguments to an event 
 handler, making this common case easy to program.
 
 But sometimes an event handler needs other data inputs

docs/Debugging.md

@@ -2,7 +2,7 @@
 
 This page describes a technique for 
 debugging re-frame apps. It proposes a particular combination 
-of tools. By the end, you'll be better at dominos. 
+of tools.
 
 <!-- START doctoc generated TOC please keep comment here to allow auto update -->
 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
@@ -78,8 +78,8 @@ as luck would have it, ClojureScript is a lisp and it is readily **traceable**.
 ##  How To Trace?
 
 Below, I suggest a particular combination of technologies which, working together,
- will write a trace to the devtools console. Sorry, but there's no fancy 
- SVG dashboard.  We said simple, right?
+will write a trace to the devtools console. Sorry, but there's no fancy 
+SVG dashboard.  We said simple, right?
 
 First, use clairvoyant to trace function calls and data flow. We've had 
 a couple of Clairvoyant PRs accepted, and they make it work well for us.

docs/WIP/Flow.md

@@ -68,10 +68,9 @@ pair to the next.
 
 There's a queue. 
 
-When you `dispatch`, the `event` vector is put into a FIFO queue to be processed "vey soon". 
+When you `dispatch` an event, it is put into a FIFO queue to be processed "vey soon". 
 
-It is important to the design of re-frame that event processing is  async. It is more declarative 
-and it loosens up the coupling.
+It is important to the design of re-frame that event processing is async. 
 
 On the end of the queue, is a `router` which (very soon) will:
  - pick up events one after the other