Okay, got it. It looks like you're using agents where I'd been using
atoms. Not sure if there's much of a difference for these use cases...
the one-directional flow of source -> state -> watcher update
notification -> ui change seems to work well with both agents and atoms.
Brian Marick wrote:
On Nov 30, 2013, at 10:39 AM, Sam Ritchie wrote:
> Brian, I like that too. It looks like you're providing the state when you do
> the def-action?
If I understand the question right, yes. A test of a state function would look
like:
(fact
(incrementer {:value 1} 3) => {:value 4}))
> Is the
Interesting; I had started playing with the core.async approach, and
it's good to see that Pedestal's on that same path.
Brian, I like that too. It looks like you're providing the state when
you do the def-action? Is the "self" variable "state", captured through
the closure?
Walter van der L
An alternative that I'm looking at is pedestal 0.3.0. It sort of works like
this...
;; Create a transform-channel and transform-function to handle all changes
to 'state'
(defn init []
(let [c (chan)]
(go (while true
(when-let [[path v] (! transform-chan [path v]))
;; Change the
On Nov 29, 2013, at 11:58 AM, Sam Ritchie wrote:
> 2) a defstatefn macro that defines the "mark" and "mark!" versions at the
> same time.
I do that with agents:
(def-action text :send [state number message])
… creates a `text*` and a `text>!`, where `test>!` is
(defn text>! [number message]
Hey guys,
As I start to work on more Clojurescript UI code, I've been running into
a pattern with atoms and watches that I THINK I can abstract away... but
the solution feels wrong, and I'd love to hear a better way.
Say I'm building a stopwatch for timing runners in a race. I've got a
cloju
