Docs

docs/HyperlinkedInformation/Diffs.md

@@ -17,11 +17,11 @@ So, how then to display changes in a way that's easy to understand?  I'm glad yo
 Remember X is the value immediately `before` (this epoch). And `X'` is the value `after` (the epoch has completed). 
 
 By [looking at the docs](https://clojuredocs.org/clojure.data/diff) on `diff`, you'll see
-that it calculates how two values differ, and returns a triple of values. `re-frame-trace`  
-captures and displays the first two elements of this triple as "only before" and "only after" 
-respectively. The 3rd element is ignored because it is not very interesting - it says 
-what hasn't changed, so it isn't shown.  
+that it calculates how two values differ, and returns a triple of values. `re-frame-trace`
+captures and displays the first two elements of this triple as "only before" and "only after"
+respectively. The 3rd element is ignored because it is not very interesting - it says
+what hasn't changed, so it isn't shown.
 
-To correctly interpret "Only Before" and "Only after", you'll need to spend a bit 
+To correctly interpret "Only Before" and "Only after", you'll need to spend a bit
 of time properly familiarising yourself with how `clojure.data/diff` works, but
 it will be a worthwhile time investment. 

docs/HyperlinkedInformation/UnchangedLayer2.md

@@ -1,4 +1,3 @@
-## Unchanged Layer 2 Subscriptions
 
 This document briefly explains why `re-frame-trace` gives you an option to 
 ignore unchanged layer 2 subscriptions. 
@@ -14,7 +13,7 @@ between `layer 2` and `layer 3` subscriptions:
   - `layer 3` subscriptions take values from `layer 2` nodes as inputs, and 
     compute a materialised view of those values. Just to repeat: they never directly 
     extract values from `app-db`.  They create new values where necessary, and because of it
-    they to do more serious CPU hogging work. So we never want to run 
+    they to do more serious CPU work. So we never want to run a
     `layer 3` subscriptions unless it is necessary. 
     
 This structure delivers efficiency. You see, **all** (currently instantiated) `layer 2` subscriptions 
@@ -22,24 +21,23 @@ will run **every** time `app-db` changes in any way. All of them. Every time.
 And `app-db` changes on almost every event, so we want them to be computationally 
 trivial. 
 
-If the value of a `layer 2` subscription tests `=` to its previous value, then the further  
+If the value of a `layer 2` subscription tests `=` to its previous value, then the further
 propagation of values through the signal graph will be pruned.
-The more computationally intensive `layer 3` subscriptions, and ultimately 
-the views, will only recompute if and when there has been a change in their data inputs.  
+The more computationally intensive `layer 3` subscriptions, and ultimately
+the views, will only recompute if and when there has been a change in their data inputs.
 
-We don't want your app recomputing views only to find that nothing has changed.
+We don't want your app recomputing views only to find that nothing has changed. Inefficient. 
 
 ### Back To Tracing
 
 Because `layer 2` subs run on every single modification of `app-db`, and because
-very often nothing has changed, their trace can be a bit noisy.
-
-Yes, it happened, but it just isn't that interesting.
+very often nothing has changed, their trace can be a bit noisy.  Yes, it happened, 
+but it just isn't that interesting.
 
 So `re-frame-trace` gives you the option of filtering out trace for 
-the `layer 2` subscriptions where the value this time is the same as the 
-value last time.
+the `layer 2` subscriptions where the value "this time" is the same as the 
+value "last time".
 
 On the other hand, if a `layer 2` subscription runs and its value is 
-different to last time, that's potentially fascinating and ypou'll want to 
+different to last time, that's potentially fascinating and you'll want to 
 be told all about it. :-)