re-frame.middleware
aftercljs
Middleware factory which runs a function "f" in the "after handler" position presumably for side effects. "f" is given the new value of "db". It's return value is ignored. Examples: "f" can run schema validation. Or write current state to localstorage. etc. In effect, "f" is meant to sideeffect. It gets no chance to change db. See "enrich" (if you need that.)
Middleware factory which runs a function "f" in the "after handler" position presumably for side effects. "f" is given the new value of "db". It's return value is ignored. Examples: "f" can run schema validation. Or write current state to localstorage. etc. In effect, "f" is meant to sideeffect. It gets no chance to change db. See "enrich" (if you need that.)
debugcljs
(debug handler)Middleware which logs debug information to js/console for each event. Includes a clojure.data/diff of the db, before vs after, showing the changes caused by the event.
Middleware which logs debug information to js/console for each event. Includes a clojure.data/diff of the db, before vs after, showing the changes caused by the event.
enrichcljs
Middleware factory which runs a given function "f" in the after position. "f" is (db v) -> db Unlike "after" which is about side effects, "enrich" expects f to process and alter db in some useful way, contributing to the derived data, flowing vibe. 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. 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 amoung many. "f" would need to be both adding and removing the duplicate warnings. By applying "f" in middleware, we keep the handlers simple and yet we ensure this important step is not missed.
Middleware factory which runs a given function "f" in the after position. "f" is (db v) -> db Unlike "after" which is about side effects, "enrich" expects f to process and alter db in some useful way, contributing to the derived data, flowing vibe. 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. 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 amoung many. "f" would need to be both adding and removing the duplicate warnings. By applying "f" in middleware, we keep the handlers simple and yet we ensure this important step is not missed.
log-excljs
(log-ex handler)Middleware which catches and prints any handler-generated exceptions to console. Handlers are called from within a core.async go-loop, and core.async produces a special kind of hell when in comes to stacktraces. By the time an exception has passed through a go-loop its stack is mangled beyond repair and you'll have no idea where the exception was thrown. So this middleware catches and prints to stacktrace before the core.async sausage machine has done its work.
Middleware which catches and prints any handler-generated exceptions to console. Handlers are called from within a core.async go-loop, and core.async produces a special kind of hell when in comes to stacktraces. By the time an exception has passed through a go-loop its stack is mangled beyond repair and you'll have no idea where the exception was thrown. So this middleware catches and prints to stacktrace before the core.async sausage machine has done its work.
on-changescljs
Middleware factory which acts a bit like "reaction" (but it flows into db , rather than out) It observes N inputs (paths into db) and if any of them change (as a result of the handler being run) then it runs 'f' to compute a new value, which is then assoced into the given out-path within app-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 the middlware above 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]
Middleware factory which acts a bit like "reaction" (but it flows into db , rather than out) It observes N inputs (paths into db) and if any of them change (as a result of the handler being run) then it runs 'f' to compute a new value, which is then assoced into the given out-path within app-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 the middlware above 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]
pathcljs
A middleware factory which supplies a sub-tree of db to the handler.
Works a bit like update-in. Supplies a narrowed data structure for the handler.
Afterwards, grafts the result of the handler back into db.
Usage:
(path :some :path)
(path [:some :path])
(path [:some :path] :to :here)
(path [:some :path] [:to] :here)
A middleware factory which supplies a sub-tree of `db` to the handler. Works a bit like update-in. Supplies a narrowed data structure for the handler. Afterwards, grafts the result of the handler back into db. Usage: (path :some :path) (path [:some :path]) (path [:some :path] :to :here) (path [:some :path] [:to] :here)
purecljs
(pure handler)Acts as an adaptor, allowing handlers to be writen as pure functions.
The re-frame router passes the app-db atom as the first parameter to any handler.
This middleware adapts that atom to be the value within the atom.
If you strip away the error/efficiency checks, this middleware is doing:
(reset! app-db (handler @app-db event-vec))
You don't have to use this middleware directly. It is automatically applied to
your handler's middleware when you use "register-handler".
In fact, the only way to by-pass automatic use of "pure" in your middleware
is to use the low level registration function "re-frame.handlers/register-handler-base"
Acts as an adaptor, allowing handlers to be writen as pure functions. The re-frame router passes the `app-db` atom as the first parameter to any handler. This middleware adapts that atom to be the value within the atom. If you strip away the error/efficiency checks, this middleware is doing: (reset! app-db (handler @app-db event-vec)) You don't have to use this middleware directly. It is automatically applied to your handler's middleware when you use "register-handler". In fact, the only way to by-pass automatic use of "pure" in your middleware is to use the low level registration function "re-frame.handlers/register-handler-base"
trim-vcljs
(trim-v handler)Middleware which removes the first element of v, allowing you to write more aesthetically pleasing handlers. No leading underscore on the event-v! Your handlers will look like this: (defn my-handler [db [x y z]] ;; <-- instead of [_ x y z] ....)
Middleware which removes the first element of v, allowing you to write
more aesthetically pleasing handlers. No leading underscore on the event-v!
Your handlers will look like this:
(defn my-handler
[db [x y z]] ;; <-- instead of [_ x y z]
....)
undoablecljs
A Middleware factory which stores an undo checkpoint. "explanation" can be either a string or a function. If it is a function then must be: (db event-vec) -> string. "explanation" can be nil. in which case "" is recorded.
A Middleware factory which stores an undo checkpoint. "explanation" can be either a string or a function. If it is a function then must be: (db event-vec) -> string. "explanation" can be nil. in which case "" is recorded.
cljdoc is a website building & hosting documentation for Clojure/Script libraries
× close