re-frame.interceptor — district0x.re-frame/ipfs-fx 1.0.0

->interceptor clj/s

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

Create an interceptor from named arguments

assoc-coeffect clj/s

(assoc-coeffect context key value)

assoc-effect clj/s

(assoc-effect context key value)

enqueue clj/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.

execute clj/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.

get-coeffect clj/s

(get-coeffect context)

(get-coeffect context key)

(get-coeffect context key not-found)

get-effect clj/s

(get-effect context)

(get-effect context key)

(get-effect context key not-found)

interceptor? clj/s

(interceptor? m)

mandatory-interceptor-keys clj/s

update-coeffect clj/s

(update-coeffect context key f & args)