          :after  (fn [context]                         ;; you normally want to change :effects
                    (let [db (get-effect context :db)]  ;; (get-in context [:effects :db])
                      (assoc-effect context :http-ajax {...}])))))
-   "
+  "
   [& {:as m :keys [id before after]}]
   (utils/apply-kw interceptor/->interceptor m))
 



;; -- dispatch ----------------------------------------------------------------
(defn dispatch
  "Queue `event` for processing by re-frame's event handling machinery.

  `event` is a vector and the first element is typically a keyword which
  identifies the kind of event.

  The event will be added to the end of a FIFO processing queue. So,
  event handling does not happen immediately. It will likely happen
  'very soon', bit not now. And if the queue already contains events,
  they will be processed first.

  Usage:
      


;; -- subscriptions -----------------------------------------------------------
(defn reg-sub
  "A call to `reg-sub` associates two functions with a `query-id`. 
   
  These two functions combine to provide the 'mechanism' for creating a node 
  in the Signal Graph, for the specified `query-id`. 
  
  The three arguments are: 
   
  - `query-id` - typically a namespaced keyword (later used in subscribe)
  - optionally, an `input signals` function which returns the input data
    flows required by this kind of node. 
  - a `computation function` which computes the value of the node (from the input data flows)
     
  Later, during app execution, a call to `(subscribe [:sub-id 3 :blue])`,
  will trigger the need for a new Signal Graph node (for the query `[:sub-id 3 :blue]`).
  And that means creating a new `:sub-id` node. To do that the two functions 
  associated with `:sub-id` are looked up and used.

  Just to repeat:  calling `reg-sub` does not immediately create a node. It only registers 
  'the mechanism' (the two functions) by which nodes can be created later, when a node is 
  bought into existence by the use of `subscribe` in a `View Function`.

  The `computation function` is expected to take two arguments:
  
    - `input-values` - the values which flow into this node
    - `query-vector` - the vector given to `subscribe`
  
  and it returns a computed value (which then becomes the output of the node)

  When `computation function` is called, the 2nd `query-vector` argument will be that 
  vector supplied to the `subscribe`. So, if the call was `(subscribe [:sub-id 3 :blue])`,
  then the `query-vector` supplied to the computaton function will be `[:sub-id 3 :blue]`.

  The argument(s) supplied between `query-id` and the `computation-function` 
  can vary in 3 ways, but whatever is there defines the `input signals` part 
  of `the mechanism`, specifying what input values \"flow into\" the 
  `computation function` (as the 1st argument) when it is called.

  `reg-sub` can be called in one of three ways, because there are three ways 
  to define the input signals part. But note, the 2nd method, in which a 
  `signals function` is explicitly supplied, is the most canonical and 
  instructive. The other two are really just sugary variations.

  First variation - no input signal function given:

      (reg-sub
        :query-id
