Spelling fixes

CHANGES.md

@@ -67,7 +67,7 @@ Joking aside, this is a substantial release which will change how you use re-fra
     Reagent available). But you can debug your event handler tests using full JVM tooling goodness.
     
     @samroberton and @escherize have provided the thought leadership and drive here.  They converted 
-    re-frame to `.cljc`, supplying plugable interop for both the `js` and `jvm` platforms.
+    re-frame to `.cljc`, supplying pluggable interop for both the `js` and `jvm` platforms.
 
     Further, they have worked with @danielcompton to create a library of testing utilities which 
     will hopefully evolve into a nice step forward on both platforms: <br>
@@ -93,7 +93,7 @@ Joking aside, this is a substantial release which will change how you use re-fra
     successful part of the framework.  We thought we were happy.
     
     But recently @steveb8n gave a cljsyd talk on 
-    Pedistal's Interceptor pattern which suddenly transformed them from 
+    Pedestal's Interceptor pattern which suddenly transformed them from 
     arcane to delightfully simple in 20 mins. Interceptors are 
     really "middleware via data" rather than "middleware via higher order functions".  
     So it is another way of doing the same thing, but thanks to @steveb8n 
@@ -176,7 +176,7 @@ Joking aside, this is a substantial release which will change how you use re-fra
 
 Breaking:
   - removed middleware `log-ex`. It is no longer needed because browsers now correctly report the
-    throw site of re-thown exceptions.  In the unlikely event that you absolutely still need it,
+    throw site of re-thrown exceptions.  In the unlikely event that you absolutely still need it,
     the source for `log-ex` is still in `middleware.cljs`, commented out.  Just transfer it to your project.
 
   - `debug` middleware now produces slightly different output (to console). So no code will need to change,
@@ -197,8 +197,8 @@ Fixed:
 
 New API:
   - [#118](https://github.com/Day8/re-frame/pull/118) - Add `add-post-event-callback` to the API.
-    @pupeno is developing [preprender](https://carouselapps.com/prerenderer) which looks pretty neat.
-    Support this effort by adding a way for preprender to hook event processing.
+    @pupeno is developing [prerenderer](https://carouselapps.com/prerenderer) which looks pretty neat.
+    Support this effort by adding a way for prerenderer to hook event processing.
 
   - `on-changes` middleware now official. No longer experimental.
 
@@ -250,7 +250,7 @@ Headline:
       - mean apps, in production, stand a chance of reporting UHE
         to the user, and can perhaps even recover to a sane state.
   - #53 Fix Logging And Error Reporting
-    You can now provide your own logging fucntions.
+    You can now provide your own logging functions.
     Further explanation [here](https://github.com/Day8/re-frame/wiki/FAQ#3-can-re-frame-use-my-logging-functions).
 
 Deprecated:

docs/Coeffects.md

@@ -86,22 +86,22 @@ right value. Nice! But how do we make this magic happen?
 ### Abracadabra 
 
 Each time an event handler is executed, a brand new `context` 
-is created, and within that `context` is a brand new `:coeffect` 
+is created, and within that `context` is a brand new `:coeffects` 
 map, which is initially totally empty.
 
-That pristine `context` value (containing a pristine `:coeffect` map) is threaded 
+That pristine `context` value (containing a pristine `:coeffects` map) is threaded 
 through a chain of Interceptors before it finally reaches our event handler,
 sitting on the end of a chain, itself wrapped up in an interceptor. We know  
 this story well from a previous tutorial. 
 
 So, all members of the Interceptor chain have the opportunity to add to `:coeffects` 
-via their `:before` function.  This is where `:coeffect` magic happens. This is how 
-new keys can be added to `:coeffect`, so that later our event handler magically finds the 
+via their `:before` function.  This is where `:coeffects` magic happens. This is how 
+new keys can be added to `:coeffects`, so that later our event handler magically finds the 
 right data (like `:local-store`) in its `cofx` argument. It is the Interceptors.
 
 ### Which Interceptors?
 
-If Interceptors put data in `:coeffect`, then we'll need to add the right ones
+If Interceptors put data in `:coeffects`, then we'll need to add the right ones
 when we register our event handler. 
 
 Something like this (this handler is the same as before, except for one detail):    
@@ -125,7 +125,7 @@ to our event handler (`cofx`).
 `inject-cofx` is part of the re-frame API.
 
 It is a function which returns an Interceptor whose `:before` function loads 
-a key/value pair into a `context's` `:coeffect` map.
+a key/value pair into a `context's` `:coeffects` map.
  
 `inject-cofx` takes either one or two arguments. The first is always the `id` of the coeffect 
 required (called a `cofx-id`). The 2nd is an optional addition value. 

docs/Debugging-Event-Handlers.md

@@ -95,7 +95,7 @@ So that `specific-interceptor` could be something required for just this one
 event handler, and it can be combined the standard ones.  
 
 Wait on! "I see a problem", you say.  `standard-interceptors` is a `vector`, and it 
-is within another `vector` allong side `specific-interceptor` - so that's 
+is within another `vector` along side `specific-interceptor` - so that's 
 nested vectors of interceptors!  
 
 No problem, re-frame uses `flatten` to take out all the nesting - the 

docs/Interceptors.md

@@ -317,7 +317,7 @@ Notes:
   1.  Notice how this wrapper extracts data from the `context's` `:coeffects` 
       and then calls the handler with that data  (a handler must be called with `db` and `event`)
   2.  Equally notice how this wrapping takes the return value from the `-db` 
-      handler and puts it into `context's` `:effect`
+      handler and puts it into `context's` `:effects`
   3.  The modified `context` (it has a new `:effects`) is returned
   3.  This is all done in `:before`.  There is no `:after` (it is a noop).  But this 
       could have been reversed with the work happening in `:after` and `:before` a noop. Shrug.

src/re_frame/cofx.cljc

@@ -33,7 +33,7 @@
 
    Given an `id`, and an optional value, lookup the registered coeffect
    handler (previously registered via `reg-cofx`) and it with two arguments:
-   the current value of `:coeffect` and, optionally, the value. The registered handler
+   the current value of `:coeffects` and, optionally, the value. The registered handler
    is expected to return a modified coeffect.
    "
   ([id]

src/re_frame/core.cljc

@@ -45,7 +45,7 @@
 
 ;; --  subscriptions
 (defn reg-sub-raw
-  "Associate a given `query id` with a given subscription handler fucntion `handler-fn`
+  "Associate a given `query id` with a given subscription handler function `handler-fn`
    which is expected to take two arguments: app-db and query vector, and return
    a `reaction`.
 

src/re_frame/interceptor.cljc

@@ -84,9 +84,9 @@
   Returns updated `context`. Ie. the `context` which has been threaded
   through all interceptor functions.
 
-  Generally speaking, an interceptor's `:before` fucntion will (if present)
-  add to a `context's` `:coeffect`, while it's `:after` function
-  will modify the `context`'s `:effect`.  Very approximately.
+  Generally speaking, an interceptor's `:before` function will (if present)
+  add to a `context's` `:coeffects`, while it's `:after` function
+  will modify the `context`'s `:effects`.  Very approximately.
 
   But because all interceptor functions are given `context`, and can
   return a modified version of it, the way is clear for an interceptor
@@ -179,7 +179,7 @@
    The first few interceptors in a chain will likely have `:before`
    functions which \"prime\" the `context` by adding the event, and
    the current state of app-db into `:coeffects`. But interceptors can
-   add whatever they want to `:coeffect` - perhaps the event handler needs
+   add whatever they want to `:coeffects` - perhaps the event handler needs
    some information from localstore, or a random number, or access to
    a DataScript connection.
 

src/re_frame/router.cljc

@@ -131,7 +131,7 @@
             ;; So, for example, the next line should be interpreted as:
             ;; if you are in state ":idle" and a trigger ":add-event"
             ;; happens, then move the FSM to state ":scheduled" and execute
-            ;; that two-part "do" fucntion.
+            ;; that two-part "do" function.
             [:idle :add-event] [:scheduled #(do (-add-event this arg)
                                                 (-run-next-tick this))]
 

src/re_frame/std_interceptors.cljc

@@ -144,7 +144,7 @@
 
   Notes:
     1. cater for `path` appearing more than once in an interceptor chain.
-    2. `:effect` may not contain `:db` effect. Which means no change to
+    2. `:effects` may not contain `:db` effect. Which means no change to
        `:db` should be made.
   "
   [& args]