- this now happens in the :running state
- just like a run-queue, but with an unconditional handling of the
first item on the queue
- no need to trigger here
- pause-run -> pause
- begin-resume -> resume
- no longer a multi-step process
- begin-run -> run-queue
- so all action function names match their keywords
- full align vectors on the left side within a group
- one space between left and right side
- align # marks in vectors on the right side within a group
- also arg1 -> arg
(timeout 0) resolves to using js/setTimeout which will actually take 4+
msecs in browsers. This is an eternity. The nextTick approach was
proposed by Patrick O'Brien and implemented here.
Docs on nextTick from Closure library:
Fires the provided callbacks as soon as possible after the current JS
execution context. setTimeout(…, 0) takes at least 4ms when called from
within another setTimeout(…, 0) for legacy reasons.
This will not schedule the callback as a microtask (i.e. a task that can
preempt user input or networking callbacks). It is meant to emulate what
setTimeout(_, 0) would do if it were not throttled. If you desire
microtask behavior, use goog.Promise instead.
Instead of creating a RAtom and resetting into it on a seperate side
chain of our dependency graph, we can instead return a reaction which is
the result of @@sub, achieving the same goals but with less code and
complexity.
Dynamic subscriptions allow the user to specify subscriptions that
depend on Ratoms/Reactions and will be rerun when they change. Users
will subscribe with v and a vector of dynamic values. The dynamic values
are dereffed and passed to the handler-fn. Dynamic subscriptions need to
pass a fn which takes app-db, v, and the dereffed dynamic values.
Every time a dynamic value changes, handler-fn will be rerun. This is in
contrast to standard subscriptions where handler-fn will only be run
once, although the reaction that it produces will change over time.
A concrete example of the need for this is:
1. You want to subscribe to a query on a remote server which will return
a Reaction which changes in response to server changes.
2. You want this subscription to be able to be rerun when you change one
of the query parameters.
In the current system, all views need to be aware of the possibility of
changing parameters and provide them in their subscriptions.
Example usage code:
(register-sub
:todo-dynamic
(fn todo-dynamic [_ _ [active-list]]
(let [q (q/get-query active-list)]
q)))
(register-sub
:todos
(fn todos [db _]
(let [active-list (subscribe [:active-list])
todos (subscribe [:todo-dynamic] [active-list])]
(make-reaction (fn todo-vals [] (update @todos :result #(vals (:list %))))))))
Stephen C. Gilardi
mike-thompson-day8
Mike Thompson
Daniel Compton
Colin Yates