Liking cljdoc? Tell your friends :D
All platforms.

re-frame-lib.cofx

inject-cofxclj/s

(inject-cofx state id)
(inject-cofx state id value)

Given the state, an id, and an optional, arbitrary value, returns an interceptor whose :before adds to the :coeffects (map) by calling a pre-registered 'coeffect handler' identified by the id.

The previous association of a coeffect handler with an id will have happened via a call to re-frame-lib.core/reg-cofx - generally on program startup.

Within the created interceptor, this 'looked up' coeffect handler will be called (within the :before) with two arguments:

  • the current value of :coeffects
  • optionally, the originally supplied arbitrary value

This coeffect handler is expected to modify and return its first, coeffects argument.

Example Of how inject-cofx and reg-cofx work together

  1. Early in app startup, you register a coeffect handler for :datetime:

    (re-frame-lib.core/reg-cofx state :datetime ;; usage (inject-cofx :datetime) (fn coeffect-handler [coeffect] (assoc coeffect :now (js/Date.)))) ;; modify and return first arg

  2. Later, add an interceptor to an -fx event handler, using inject-cofx:

    (re-frame-lib.core/reg-event-fx ;; we are registering an event handler state :event-id [ ... (inject-cofx :datetime) ... ] ;; <-- create an injecting interceptor (fn event-handler [coeffect event] ... in here can access (:now coeffect) to obtain current datetime ... )))

Background

coeffects are the input resources required by an event handler to perform its job. The two most obvious ones are db and event. But sometimes an event handler might need other resources.

Perhaps an event handler needs a random number or a GUID or the current datetime. Perhaps it needs access to a DataScript database connection.

If an event handler directly accesses these resources, it stops being pure and, consequently, it becomes harder to test, etc. So we don't want that.

Instead, the interceptor created by this function is a way to 'inject' 'necessary resources' into the :coeffects (map) subsequently given to the event handler at call time.

Given the `state`, an `id`, and an optional, arbitrary `value`, returns an
interceptor whose `:before` adds to the `:coeffects` (map) by calling a
pre-registered 'coeffect handler' identified by the `id`.

 The previous association of a `coeffect handler` with an `id` will have
 happened via a call to `re-frame-lib.core/reg-cofx` - generally on program startup.

 Within the created interceptor, this 'looked up' `coeffect handler` will
 be called (within the `:before`) with two arguments:
   - the current value of `:coeffects`
   - optionally, the originally supplied arbitrary `value`

 This `coeffect handler` is expected to modify and return its first, `coeffects` argument.

 Example Of how `inject-cofx` and `reg-cofx` work together
 ---------------------------------------------------------

 1. Early in app startup, you register a `coeffect handler` for `:datetime`:

    (re-frame-lib.core/reg-cofx
      state
      :datetime                        ;; usage  (inject-cofx :datetime)
      (fn coeffect-handler
        [coeffect]
        (assoc coeffect :now (js/Date.))))   ;; modify and return first arg

 2. Later, add an interceptor to an -fx event handler, using `inject-cofx`:

    (re-frame-lib.core/reg-event-fx        ;; we are registering an event handler
       state
       :event-id
       [ ... (inject-cofx :datetime) ... ]    ;; <-- create an injecting interceptor
       (fn event-handler
         [coeffect event]
         ... in here can access (:now coeffect) to obtain current datetime ... )))

 Background
 ----------

 `coeffects` are the input resources required by an event handler
 to perform its job. The two most obvious ones are `db` and `event`.
 But sometimes an event handler might need other resources.

 Perhaps an event handler needs a random number or a GUID or the current
 datetime. Perhaps it needs access to a DataScript database connection.

 If an event handler directly accesses these resources, it stops being
 pure and, consequently, it becomes harder to test, etc. So we don't
 want that.

 Instead, the interceptor created by this function is a way to 'inject'
 'necessary resources' into the `:coeffects` (map) subsequently given
 to the event handler at call time.
sourceraw docstring

inject-dbclj/s

(inject-db state)
source

kindclj/s

source

reg-cofxclj/s

(reg-cofx state id handler)

Register the given coeffect handler for the given id inside the re-frame state, for later use within inject-cofx.

id is keyword, often namespaced. handler is a function which takes either one or two arguements, the first of which is always coeffects and which returns an updated coeffects.

See the docs for inject-cofx for example use.

Register the given coeffect `handler` for the given `id` inside the re-frame
`state`, for later use within `inject-cofx`.

`id` is keyword, often namespaced.
`handler` is a function which takes either one or two arguements, the first of which is
always `coeffects` and which returns an updated `coeffects`.

See the docs for `inject-cofx` for example use.
sourceraw docstring

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

Keyboard shortcutsReport a problemcljdoc on GitHub
× close