Liking cljdoc? Tell your friends :D

frame.interceptors


->interceptorclj/s

(->interceptor & {:as m :keys [id before after]})

Create an interceptor from named arguments

Create an interceptor from named arguments
raw docstring

assoc-coeffectclj/s

(assoc-coeffect context key value)

assoc-effectclj/s

(assoc-effect context key value)

enqueueclj/s

(enqueue context interceptors)

Add a collection of interceptors to the end of context's execution :queue. Returns the updated context. In an advanced case, this function could allow an interceptor to add new interceptors to the :queue of a context.

Add a collection of `interceptors` to the end of `context's` execution `:queue`.
Returns the updated `context`.
In an advanced case, this function could allow an interceptor to add new
interceptors to the `:queue` of a context.
raw docstring

executeclj/s

(execute event-v interceptors)

Executes the given chain (coll) of interceptors. Each interceptor has this form: {:before (fn [context] ...) ;; returns possibly modified context :after (fn [context] ...)} ;; identity would be a noop Walks the queue of iterceptors from beginning to end, calling the :before fn on each, then reverse direction and walk backwards, calling the :after fn on each. The last interceptor in the chain presumably wraps an event handler fn. So the overall goal of the process is to "handle the given event". Thread a context through all calls. context has this form: {:coeffects {:event [:a-query-id :some-param] :db <original contents of app-db>} :effects {:db <new value for app-db> :dispatch [:an-event-id :param1]} :queue <a collection of further interceptors> :stack <a collection of interceptors already walked>} context has :coeffects and :effects which, if this was a web server, would be somewhat anologous to request and response respectively. coeffects will contain data like event and the initial state of db - the inputs required by the event handler (sitting presumably on the end of the chain), while handler-returned side effects are put into :effects including, but not limited to, new values for db. 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 :coeffects - perhaps the event handler needs some information from localstore, or a random number, or access to a DataScript connection. Equally, some interceptors in the chain will have :after fn which can process the side effects accumulated into :effects including but, not limited to, updates to app-db. Through both stages (before and after), context contains a :queue of interceptors yet to be processed, and a :stack of interceptors already done. In advanced cases, these values can be modified by the functions through which the context is threaded.

Executes the given chain (coll) of interceptors.
Each interceptor has this form:
    {:before  (fn [context] ...)     ;; returns possibly modified context
     :after   (fn [context] ...)}    ;; `identity` would be a noop
Walks the queue of iterceptors from beginning to end, calling the
`:before` fn on each, then reverse direction and walk backwards,
calling the `:after` fn on each.
The last interceptor in the chain presumably wraps an event
handler fn. So the overall goal of the process is to "handle
the given event".
Thread a `context` through all calls. `context` has this form:
  {:coeffects {:event [:a-query-id :some-param]
               :db    <original contents of app-db>}
   :effects   {:db    <new value for app-db>
               :dispatch  [:an-event-id :param1]}
   :queue     <a collection of further interceptors>
   :stack     <a collection of interceptors already walked>}
`context` has `:coeffects` and `:effects` which, if this was a web
server, would be somewhat anologous to `request` and `response`
respectively.
`coeffects` will contain data like `event` and the initial
state of `db` -  the inputs required by the event handler
(sitting presumably on the end of the chain), while handler-returned
side effects are put into `:effects` including, but not limited to,
new values for `db`.
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 `:coeffects` - perhaps the event handler needs
some information from localstore, or a random number, or access to
a DataScript connection.
Equally, some interceptors in the chain will have `:after` fn
which can process the side effects accumulated into `:effects`
including but, not limited to, updates to app-db.
Through both stages (before and after), `context` contains a `:queue`
of interceptors yet to be processed, and a `:stack` of interceptors
already done.  In advanced cases, these values can be modified by the
functions through which the context is threaded.
raw docstring

get-coeffectclj/s

(get-coeffect context)
(get-coeffect context key)
(get-coeffect context key not-found)

get-effectclj/s

(get-effect context)
(get-effect context key)
(get-effect context key not-found)

interceptor?clj/s

(interceptor? m)

mandatory-interceptor-keysclj/s


update-coeffectclj/s

(update-coeffect context key f & args)

cljdoc is a website building & hosting documentation for Clojure/Script libraries

× close