   But note, the 2nd method, in which a `signal-fn` is explicitly supplied, is the most canonical and instructive. The other
   two are really just sugary variations.
 
-  1. No input signals given:
-     ```clj
-     (reg-sub
-       :query-id
-       a-computation-fn)   ;; has signature:  (fn [db query-vec]  ... ret-value)
-     ```
+  First, No input signals given:
+
+      (reg-sub
+        :query-id
+        a-computation-fn)   ;; has signature:  (fn [db query-vec]  ... ret-value)
 
      In the absence of an explicit `input-fn`, the node's input signal defaults to `app-db`
      and, as a result, the value within `app-db` (a map) is
      is given as the 1st argument when `a-computation-fn` is called.
 
 
-  2. A signal function is explicitly supplied:
-     ```clj
-     (reg-sub
-       :query-id
-       signal-fn     ;; <-- here
-       computation-fn)
-     ```
-
-     This is the most canonical and instructive of the three variations.
-
-     When a node is created from the template, the `signal-fn` will be called and it
-     is expected to return the input signal(s) as either a singleton, if there is only
-     one, or a sequence if there are many, or a map with the signals as the values.
-
-     The values from returned nominated signals will be supplied as the 1st argument to
-     the `a-computation-fn` when it is called - and subject to what this `signal-fn` returns,
-     this value will be either a singleton, sequence or map of them (paralleling
-     the structure returned by the `signal-fn`).
-
-     This example `signal-fn` returns a vector of input signals.
-     ```clj
-       (fn [query-vec dynamic-vec]
+  Second, A signal function is explicitly supplied:
+
+      (reg-sub
+        :query-id
+        signal-fn     ;; <-- here
+        computation-fn)
+
+  This is the most canonical and instructive of the three variations.
+
+  When a node is created from the template, the `signal-fn` will be called and it
+  is expected to return the input signal(s) as either a singleton, if there is only
+  one, or a sequence if there are many, or a map with the signals as the values.
+
+  The values from returned nominated signals will be supplied as the 1st argument to
+  the `a-computation-fn` when it is called - and subject to what this `signal-fn` returns,
+  this value will be either a singleton, sequence or map of them (paralleling
+  the structure returned by the `signal-fn`).
+
+  This example `signal-fn` returns a vector of input signals.
+
+      (fn [query-vec dynamic-vec]
          [(subscribe [:a-sub])
           (subscribe [:b-sub])])
-      ```
-       
-     The associated computation function must be written
-     to expect a vector of values for its first argument:
-     ```clj
-     (fn [[a b] query-vec]     ;; 1st argument is a seq of two values
-       ....)
-     ```
-
-     If, on the other hand, the signal function was simpler and returned a singleton, like this:
-     ```clj
+
+  The associated computation function must be written
+  to expect a vector of values for its first argument:
+
+      (fn [[a b] query-vec]     ;; 1st argument is a seq of two values
+        ....)
+
+  If, on the other hand, the signal function was simpler and returned a singleton, like this:
+
      (fn [query-vec dynamic-vec]
        (subscribe [:a-sub]))
-     ```
-     then the associated computation function must be written to expect a single value
-     as the 1st argument:
-     ```clj
-       (fn [a query-vec]       ;; 1st argument is a single value
+
+  then the associated computation function must be written to expect a single value
+  as the 1st argument:
+
+      (fn [a query-vec]       ;; 1st argument is a single value
          ...)
-      ```
-
-     Further Note: variation #1 above, in which an `input-fn` was not supplied, like this:
-     ```clj
-     (reg-sub
-       :query-id
-       a-computation-fn)   ;; has signature:  (fn [db query-vec]  ... ret-value)
-     ```
-     is the equivalent of using this
-     2nd variation and explicitly suppling a `signal-fn` which returns `app-db`:
-     ```clj
-     (reg-sub
-       :query-id
-       (fn [_ _]  re-frame/app-db)   ;; <--- explicit input-fn
-       a-computation-fn)             ;; has signature:  (fn [db query-vec]  ... ret-value)
-     ```
-
-  3. Syntax Sugar
-     ```clj
-     (reg-sub
-       :a-b-sub
-       :<- [:a-sub]
-       :<- [:b-sub]
-       (fn [[a b] query-vec]    ;; 1st argument is a seq of two values
-         {:a a :b b}))
-     ```
-
-     This 3rd variation is just syntactic sugar for the 2nd.  Instead of providing an
-     `signals-fn` you provide one or more pairs of `:<-` and a subscription vector.
-
-     If you supply only one pair a singleton will be supplied to the computation function,
-     as if you had supplied a `signal-fn` returning only a single value:
-
-     ```clj
-     (reg-sub
-       :a-sub
-       :<- [:a-sub]
-       (fn [a query-vec]      ;; only one pair, so 1st argument is a single value
-         ...))
-     ```
-
-    For further understanding, read the tutorials, and look at the detailed comments in
-    /examples/todomvc/src/subs.cljs
+
+  Further Note: variation #1 above, in which an `input-fn` was not supplied, like this:
+
+      (reg-sub
+        :query-id
+        a-computation-fn)   ;; has signature:  (fn [db query-vec]  ... ret-value)
+
+  is the equivalent of using this
+  2nd variation and explicitly suppling a `signal-fn` which returns `app-db`:
+
+      (reg-sub
+        :query-id
+        (fn [_ _]  re-frame/app-db)   ;; <--- explicit input-fn
+        a-computation-fn)             ;; has signature:  (fn [db query-vec]  ... ret-value)
+
+  Third, Syntax Sugar
+
+      (reg-sub
+        :a-b-sub
+        :<- [:a-sub]
+        :<- [:b-sub]
+        (fn [[a b] query-vec]    ;; 1st argument is a seq of two values
+          {:a a :b b}))
+
+  This 3rd variation is just syntactic sugar for the 2nd.  Instead of providing an
+  `signals-fn` you provide one or more pairs of `:<-` and a subscription vector.
+
+  If you supply only one pair a singleton will be supplied to the computation function,
+  as if you had supplied a `signal-fn` returning only a single value:
+
+
+      (reg-sub
+        :a-sub
+        :<- [:a-sub]
+        (fn [a query-vec]      ;; only one pair, so 1st argument is a single value
+          ...))
+
+  For further understanding, read the tutorials, and look at the detailed comments in
+  /examples/todomvc/src/subs.cljs
   "
   [query-id & args]
   (apply subs/reg-sub (into [query-id] args)))

  `js/console.debug`. See examples/todomvc/src/events.cljs for use.

  Output includes:
   
  1. the event vector
  2. a `clojure.data/diff` of db, before vs after, which shows
     the changes caused by the event handler. To understand the output,

(defn add-post-event-callback
  "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.

   This is useful in advanced cases like:

     - you are implementing a complex bootstrap pipeline
     - you want to create your own handling infrastructure, with perhaps multiple
       handlers for the one event, etc.  Hook in here.
