(reg-pull-sub sub-name pattern)
Syntax sugar for writing pull queries. It allows writing pull subscription in a very simple way:
(re-posh/reg-pull-sub :pull-id '[*]) ;;<- pull pattern
It's possible to subscribe to this pull query with
(re-posh/subscibe [:pull-id id])
Where id is an entity id
Syntax sugar for writing pull queries. It allows writing pull subscription in a very simple way: (re-posh/reg-pull-sub :pull-id '[*]) ;;<- pull pattern It's possible to subscribe to this pull query with (re-posh/subscibe [:pull-id id]) Where id is an entity id
(reg-query-sub sub-name query)
Syntax sugar for writing queries. It allows writing query subscription in a very simple way:
(re-posh/reg-query-sub :query-id '[:find ... :in $ $1 $2 ;; <- all variables go here :where ...])
It's possible to subscibe to this query with
(re-posh/subscribe [:query-id var-1 var-2])
so that variables var-1
and var-2
will be automatically sent to :in
form
Syntax sugar for writing queries. It allows writing query subscription in a very simple way: (re-posh/reg-query-sub :query-id '[:find ... :in $ $1 $2 ;; <- all variables go here :where ...]) It's possible to subscibe to this query with (re-posh/subscribe [:query-id var-1 var-2]) so that variables `var-1` and `var-2` will be automatically sent to `:in` form
(reg-sub query-id & args)
For a given query-id
register a config
function and input signals
At an abstract level, a call to this function allows you to register 'the mechanism'
to later fulfil a call to (subscribe [query-id ...])
.
To say that another way, reg-sub allows you to create a template for a node
in the signal graph. But note: reg-sub does not cause a node to be created.
It simply allows you to register the template from which such a
node could be created, if it were needed, sometime later, when the call
to subscribe
is made.
reg-sub needs three things:
query-id
The query-id
is always the 1st argument to reg-sub and it is typically
a namespaced keyword.
A config function is always the last argument and it has this general form:
(input-signals, query-vector) -> a-value
What goes in between the 1st and last args can vary, but whatever is there will define the input signals part of the template, and, as a result, it will control what values the config functions gets as a first argument. There's 3 ways this function can be called - 3 ways to supply input signals:
No input signals given:
(reg-sub
:query-id
a-config-fn) ;; (fn [db v] ... a-value)
The node's input signal defaults to datascript database, and the value within ds
is
is given as the 1st argument to the computation function.
A signal function is supplied:
(reg-sub :query-id signal-fn ;; <-- here, the form is (fn [db v] ... signal | [signal]) config-fn)
When a node is created from the template, the signal-fn
will be called and it
is expected to return the input signal(s) as either a singleton, if there is only
one, or a sequence if there are many.
The values from the nominated signals will be supplied as the 1st argument to the
config function - either a singleton or sequence, paralleling
the structure returned by the signal function.
Here, is an example signal-fn, which returns a vector of input signals.
(fn [query-vec]
[(subscribe [:a-sub])
(subscribe [:b-sub])])
For that signal function, the config function must be written
to expect a vector of values for its first argument.
(fn [[a b] _] ....)
If the signal function was simpler and returned a singleton, like this:
(fn [query-vec dynamic-vec]
(subscribe [:a-sub]))
then the config function must be written to expect a single value
as the 1st argument:
(fn [a _] ...)
Syntax Sugar
(reg-sub :a-b-sub :<- [:a-sub] :<- [:b-sub] (fn [[a b] [_]] {:a a :b b}))
This 3rd variation is syntactic sugar for the 2nd. Pairs are supplied instead
of an input signals
functions. Each pair starts with a :<-
and a subscription
vector follows.
For a given `query-id` register a `config` function and input `signals` At an abstract level, a call to this function allows you to register 'the mechanism' to later fulfil a call to `(subscribe [query-id ...])`. To say that another way, reg-sub allows you to create a template for a node in the signal graph. But note: reg-sub does not cause a node to be created. It simply allows you to register the template from which such a node could be created, if it were needed, sometime later, when the call to `subscribe` is made. reg-sub needs three things: - a `query-id` - the required inputs for this node - a function that generates config for query or pull for this node The `query-id` is always the 1st argument to reg-sub and it is typically a namespaced keyword. A config function is always the last argument and it has this general form: `(input-signals, query-vector) -> a-value` What goes in between the 1st and last args can vary, but whatever is there will define the input signals part of the template, and, as a result, it will control what values the config functions gets as a first argument. There's 3 ways this function can be called - 3 ways to supply input signals: 1. No input signals given: (reg-sub :query-id a-config-fn) ;; (fn [db v] ... a-value) The node's input signal defaults to datascript database, and the value within `ds` is is given as the 1st argument to the computation function. 2. A signal function is supplied: (reg-sub :query-id signal-fn ;; <-- here, the form is (fn [db v] ... signal | [signal]) config-fn) When a node is created from the template, the `signal-fn` will be called and it is expected to return the input signal(s) as either a singleton, if there is only one, or a sequence if there are many. The values from the nominated signals will be supplied as the 1st argument to the config function - either a singleton or sequence, paralleling the structure returned by the signal function. Here, is an example signal-fn, which returns a vector of input signals. (fn [query-vec] [(subscribe [:a-sub]) (subscribe [:b-sub])]) For that signal function, the config function must be written to expect a vector of values for its first argument. (fn [[a b] _] ....) If the signal function was simpler and returned a singleton, like this: (fn [query-vec dynamic-vec] (subscribe [:a-sub])) then the config function must be written to expect a single value as the 1st argument: (fn [a _] ...) 3. Syntax Sugar (reg-sub :a-b-sub :<- [:a-sub] :<- [:b-sub] (fn [[a b] [_]] {:a a :b b})) This 3rd variation is syntactic sugar for the 2nd. Pairs are supplied instead of an `input signals` functions. Each pair starts with a `:<-` and a subscription vector follows.
cljdoc is a website building & hosting documentation for Clojure/Script libraries
× close