Merge pull request #212 from smahood/master

A bit of clean up work

src/re_frame/core.cljc

@@ -67,7 +67,7 @@
   "Register the given `id`, typically a keyword, with the combination of
   `db-handler` and an interceptor chain.
   `db-handler` is a function: (db event) -> db
-  `interceptors` is a collection of interceptors, possibly nested (needs flattenting).
+  `interceptors` is a collection of interceptors, possibly nested (needs flattening).
   `db-handler` is wrapped in an interceptor and added to the end of the chain, so in the end
    there is only a chain.
    The necessary effects and coeffects handler are added to the front of the
@@ -102,7 +102,7 @@
 (def set-loggers! loggers/set-loggers!)
 
 ;; If you are writing an extension to re-frame, like perhaps
-;; an effeects handler, you may want to use re-frame logging.
+;; an effects handler, you may want to use re-frame logging.
 ;;
 ;; usage:  (console :error "this is bad: " a-variable " and " anotherv)
 ;;         (console :warn "possible breach of containment wall at: " dt)
@@ -137,10 +137,10 @@
       nil)))
 
 
-;; -- Event Procssing Callbacks
+;; -- Event Processing Callbacks
 
 (defn add-post-event-callback
-  "Registers a function `f` to be called after each event is procecessed
+  "Registers a function `f` to be called after each event is processed
    `f` will be called with two arguments:
     - `event`: a vector. The event just processed.
     - `queue`: a PersistentQueue, possibly empty, of events yet to be processed.
@@ -166,7 +166,7 @@
 
 
 ;; --  Deprecation Messages
-;; Assisting the v0.0.7 ->  v0.0.8 tranistion.
+;; Assisting the v0.0.7 ->  v0.0.8 transition.
 (defn register-handler
   [& args]
   (console :warn  "re-frame:  \"register-handler\" has been renamed \"reg-event-db\" (look for registration of " (str (first args)) ")")

src/re_frame/db.cljc

@@ -4,7 +4,7 @@
 
 ;; -- Application State  --------------------------------------------------------------------------
 ;;
-;; Should not be accessed directly by application code
+;; Should not be accessed directly by application code.
 ;; Read access goes through subscriptions.
 ;; Updates via event handlers.
 (def app-db (ratom {}))

src/re_frame/events.cljc

@@ -35,7 +35,7 @@
   "Associate the given event `id` with the given collection of `interceptors`.
 
    `interceptors` may contain nested collections and there may be nils
-   at any level,so process this sturcuture into a simple, nil-less vector
+   at any level,so process this structure into a simple, nil-less vector
    before registration.
 
    An `event handler` will likely be at the end of the chain (wrapped in an interceptor)."

src/re_frame/interceptor.cljc

@@ -17,7 +17,7 @@
 
 
 (defn ->interceptor
-  "Create an interceptor from named arguements"
+  "Create an interceptor from named arguments"
   [& {:as m :keys [name id before after]}]      ;; XXX remove `name` in due course - only in there as a backwards compat thing
   (when debug-enabled?
     (if name                                    ;; XXX remove in due course

src/re_frame/interop.cljs

@@ -9,7 +9,7 @@
 
 (def after-render reagent.core/after-render)
 
-;; Make sure the Google Closure compiler sees this as a boolean constatnt,
+;; Make sure the Google Closure compiler sees this as a boolean constant,
 ;; otherwise Dead Code Elimination won't happen in `:advanced` builds.
 ;; Type hints have been liberally sprinkled.
 ;; https://developers.google.com/closure/compiler/docs/js-for-compiler

src/re_frame/router.cljc

@@ -8,7 +8,7 @@
 ;;
 ;; A call to "re-frame.core/dispatch" places an event on a queue for processing.
 ;; A short time later, the handler registered to handle this event will be run.
-;; What follows is the implemtation of this process.
+;; What follows is the implementation of this process.
 ;;
 ;; The task is to process queued events in a perpetual loop, one after
 ;; the other, FIFO, calling the registered event-handler for each, being idle when
@@ -32,14 +32,14 @@
 ;;   - maintain a FIFO queue of `dispatched` events.
 ;;   - when a new event arrives, "schedule" processing of this queue using
 ;;     goog.async.nextTick, which means it will happen "very soon".
-;;   - when processing events, one after the other, do ALL the those currently
+;;   - when processing events, one after the other, do ALL the currently
-;;     queued. Don't stop. Don't yield to the browser. Hog that CPU.
+;;     queued events. Don't stop. Don't yield to the browser. Hog that CPU.
 ;;   - but if any new events are dispatched during this cycle of processing,
 ;;     don't do them immediately. Leave them queued. Yield first to the browser,
 ;;     and do these new events in the next processing cycle. That way we drain
 ;;     the queue up to a point, but we never hog the CPU forever. In
 ;;     particular, we handle the case where handling one event will beget
-;;     another event. The freshly begatted event will be handled next cycle,
+;;     another event. The freshly begotten event will be handled next cycle,
 ;;     with yielding in-between.
 ;;   - In some cases, an event should not be handled until after the GUI has been
 ;;     updated, i.e., after the next Reagent animation frame. In such a case,
@@ -118,9 +118,9 @@
   (-fsm-trigger
     [this trigger arg]
 
-    ;; The following "case" impliments the Finite State Machine.
+    ;; The following "case" implements the Finite State Machine.
     ;; Given a "trigger", and the existing FSM state, it computes the
-    ;; new FSM state and the tranistion action (function).
+    ;; new FSM state and the transition action (function).
 
     (let [[new-fsm-state action-fn]
           (case [fsm-state trigger]
@@ -237,7 +237,7 @@
 
 
 (defn dispatch-sync
-  "Sychronously (immediaetly!) process the given event using the registered handler.
+  "Sychronously (immediately!) process the given event using the registered handler.
 
   Generally, you shouldn't use this - you should use `dispatch` instead.  It
   is an error to use `dispatch-sync` within an event handler.

src/re_frame/subs.cljc

@@ -34,7 +34,7 @@
   "cache the reaction r"
   [query-v dynv r]
   (let [cache-key [query-v dynv]]
-    ;; when this reaction is nolonger being used, remove it from the cache
+    ;; when this reaction is no longer being used, remove it from the cache
     (add-on-dispose! r #(do (swap! query->reaction dissoc cache-key)
                             #_(console :log "Removing subscription:" cache-key)))
     ;; cache this reaction, so it can be used to deduplicate other, later "=" subscriptions
@@ -116,7 +116,7 @@
           (subs/subscribe [:b-sub])])
        (fn [[a b] [_]] {:a a :b b}))
 
-  Two functions provided. The 2nd is computation fucntion, as before. The 1st
+  Two functions provided. The 2nd is computation function, as before. The 1st
   is returns what `input signals` should be provided to the computation. The
   `input signals` function is called with two arguments: the query vector
   and the dynamic vector. The return value can be singleton reaction or
@@ -133,7 +133,7 @@
   "
   [query-id & args]
   (let [computation-fn (last args)
-        input-args     (butlast args)    ;; may be empty, or one fn, or pairs of  :<- / vetor
+        input-args     (butlast args)    ;; may be empty, or one fn, or pairs of  :<- / vector
         err-header     (str "re-frame: reg-sub for " query-id ", ")
         inputs-fn      (case (count input-args)
                          ;; no `inputs` function provided - give the default