re-posh.subs — re-posh 0.3.0

execute-sub cljs

reg-pull-sub cljs

(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

reg-query-sub cljs

(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

reg-sub cljs

(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:

• 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.