contains re-frame supplied, standard interceptors
contains re-frame supplied, standard interceptors
(after f)
Interceptor factory which runs a given function f
in the "after"
position, presumably for side effects.
f
is called with two arguments: the effects
value of :db
(or the coeffect
value of db if no db effect is returned) and the event.
Its return value is ignored so f
can only side-effect.
Example use:
f
runs schema validation (reporting any errors found)f
writes some aspect of db to localstorage.Interceptor factory which runs a given function `f` in the "after" position, presumably for side effects. `f` is called with two arguments: the `effects` value of `:db` (or the `coeffect` value of db if no db effect is returned) and the event. Its return value is ignored so `f` can only side-effect. Example use: - `f` runs schema validation (reporting any errors found) - `f` writes some aspect of db to localstorage.
(ctx-handler->interceptor handler-fn)
Returns an interceptor which wraps the kind of event handler given to reg-event-ctx
.
These advanced handlers take one argument: context
and they return a modified context
.
Example:
(fn [context]
(enqueue context [more interceptors]))
Returns an interceptor which wraps the kind of event handler given to `reg-event-ctx`. These advanced handlers take one argument: `context` and they return a modified `context`. Example: (fn [context] (enqueue context [more interceptors]))
(db-handler->interceptor handler-fn)
Returns an interceptor which wraps the kind of event handler given to reg-event-db
.
These handlers take two arguments; db
and event
, and they return db
.
(fn [db event] ....)
So, the interceptor wraps the given handler:
:coeffects
keys: db and event:effects
Returns an interceptor which wraps the kind of event handler given to `reg-event-db`. These handlers take two arguments; `db` and `event`, and they return `db`. (fn [db event] ....) So, the interceptor wraps the given handler: 1. extracts two `:coeffects` keys: db and event 2. calls handler-fn 3. stores the db result back into context's `:effects`
An interceptor which logs data about the handling of an event.
Includes a clojure.data/diff
of the db, before vs after, showing
the changes caused by the event handler.
You'd typically want this interceptor after (to the right of) any path interceptor.
Warning: calling clojure.data/diff on large, complex data structures can be slow. So, you won't want this interceptor present in production code. See the todomvc example to see how to exclude interceptors from production code.
An interceptor which logs data about the handling of an event. Includes a `clojure.data/diff` of the db, before vs after, showing the changes caused by the event handler. You'd typically want this interceptor after (to the right of) any path interceptor. Warning: calling clojure.data/diff on large, complex data structures can be slow. So, you won't want this interceptor present in production code. See the todomvc example to see how to exclude interceptors from production code.
(enrich f)
Interceptor factory which runs the given function f
in the after handler
position. f
is called with two arguments: db
and v
, and is expected to
return a modified db
.
Unlike the after
inteceptor which is only about side effects, enrich
expects f to process and alter the given db
coeffect in some useful way,
contributing to the derived data, flowing vibe.
Example Use:
Imagine that todomvc needed to do duplicate detection - if any two todos had the same text, then highlight their background, and report them in a warning down the bottom of the panel.
Almost any action (edit text, add new todo, remove a todo) requires a complete reassesment of duplication errors and warnings. Eg: that edit update might have introduced a new duplicate or removed one. Same with a todo removal.
And to perform this enrichment, a function has to inspect all the todos, possibly set flags on each, and set some overall list of duplicates. And this duplication check might just be one check among many.
f
would need to be both adding and removing the duplicate warnings.
By applying f
in an :after
interceptor, we keep the handlers
simple and yet we ensure this important step is not missed.
Interceptor factory which runs the given function `f` in the `after handler` position. `f` is called with two arguments: `db` and `v`, and is expected to return a modified `db`. Unlike the `after` inteceptor which is only about side effects, `enrich` expects f to process and alter the given `db` coeffect in some useful way, contributing to the derived data, flowing vibe. Example Use: Imagine that todomvc needed to do duplicate detection - if any two todos had the same text, then highlight their background, and report them in a warning down the bottom of the panel. Almost any action (edit text, add new todo, remove a todo) requires a complete reassesment of duplication errors and warnings. Eg: that edit update might have introduced a new duplicate or removed one. Same with a todo removal. And to perform this enrichment, a function has to inspect all the todos, possibly set flags on each, and set some overall list of duplicates. And this duplication check might just be one check among many. `f` would need to be both adding and removing the duplicate warnings. By applying `f` in an `:after` interceptor, we keep the handlers simple and yet we ensure this important step is not missed.
(fx-handler->interceptor handler-fn)
Returns an interceptor which wraps the kind of event handler given to reg-event-fx
.
These handlers take two arguments; coeffects
and event
, and they return effects
.
(fn [coeffects event] {:db ... :dispatch ...})
Wrap handler in an interceptor so it can be added to (the RHS) of a chain:
:coeffects
:effects
Returns an interceptor which wraps the kind of event handler given to `reg-event-fx`. These handlers take two arguments; `coeffects` and `event`, and they return `effects`. (fn [coeffects event] {:db ... :dispatch ...}) Wrap handler in an interceptor so it can be added to (the RHS) of a chain: 1. extracts `:coeffects` 2. call handler-fn giving coeffects 3. stores the result back into the `:effects`
(on-changes f out-path & in-paths)
Interceptor factory which acts a bit like reaction
(but it flows into db
, rather than out)
It observes N paths in db
and if any of them test not indentical? to their previous value
(as a result of a handler being run) then it runs f
to compute a new value, which is
then assoced into the given out-path
within db
.
Usage:
(defn my-f [a-val b-val] ... some computation on a and b in here)
(on-changes my-f [:c] [:a] [:b])
Put this Interceptor on the right handlers (ones which might change :a or :b). It will:
f
each time the value at path [:a] or [:b] changesf
with the values extracted from [:a] [:b]f
into the path [:c]Interceptor factory which acts a bit like `reaction` (but it flows into `db`, rather than out) It observes N paths in `db` and if any of them test not indentical? to their previous value (as a result of a handler being run) then it runs `f` to compute a new value, which is then assoced into the given `out-path` within `db`. Usage: (defn my-f [a-val b-val] ... some computation on a and b in here) (on-changes my-f [:c] [:a] [:b]) Put this Interceptor on the right handlers (ones which might change :a or :b). It will: - call `f` each time the value at path [:a] or [:b] changes - call `f` with the values extracted from [:a] [:b] - assoc the return value from `f` into the path [:c]
(path & args)
An interceptor factory which supplies a sub-path of :db
to the handler.
It's action is somewhat analogous to update-in
. It grafts the return
value from the handler back into db.
Usage: (path :some :path) (path [:some :path]) (path [:some :path] :to :here) (path [:some :path] [:to] :here)
Notes:
path
appearing more than once in an interceptor chain.:effects
may not contain :db
effect. Which means no change to
:db
should be made.An interceptor factory which supplies a sub-path of `:db` to the handler. It's action is somewhat analogous to `update-in`. It grafts the return value from the handler back into db. Usage: (path :some :path) (path [:some :path]) (path [:some :path] :to :here) (path [:some :path] [:to] :here) Notes: 1. cater for `path` appearing more than once in an interceptor chain. 2. `:effects` may not contain `:db` effect. Which means no change to `:db` should be made.
An interceptor which removes the first element of the event vector, allowing you to write more aesthetically pleasing db handlers. No leading underscore on the event-v! Your event handlers will look like this:
(defn my-handler
[db [x y z]] ;; <-- instead of [_ x y z]
....)
An interceptor which removes the first element of the event vector, allowing you to write more aesthetically pleasing db handlers. No leading underscore on the event-v! Your event handlers will look like this: (defn my-handler [db [x y z]] ;; <-- instead of [_ x y z] ....)
cljdoc is a website building & hosting documentation for Clojure/Script libraries
× close