So one problem with doing this in a call-back handler is that of stale state.
The following won't work:
(defn query [criteria]...)
(defn cb [data ev]
(om/update! data ...)
(query @data))
(defn input-1... {:opts {:cb cb})
(defn input-2... {:opts {:cb cb})
as (update!) is asynchronous and so the @data will see the old value, not the
new value.
This is all according to documentation etc. and makes sense but throws a
wrinkle in the doing-it-via-cb method. I can of course manually apply the
change as well, but that get's lame pretty quickly.
The non-visual-om-component-controller is looking more appealing...
On Monday, 12 January 2015 10:28:55 UTC, Colin Yates wrote:
> Hi all,
>
> My use-case is that if anything in a form changes I want to do the same thing
> (e.g. validation). Actually, for this use-case I want to see if an existing
> record matches when they enter a new record.
>
> In general, I want to do action X if any of a set of cursor paths value's
> change.
>
> I could add a call to (action-x) in the on-change event for each UI
> component, which is a bit noisy. Similarly, the on-change events could put!
> into a tapped channel, one reader is the real on-change the other is
> (action-x) and so on.
>
> Or, and I really don't know if this is great or awful, I could define an
> om-component which has no UI at all, but implements (action-x) on render.
>
> How do you handle this?
>
> (P.S. It is at times like this I miss AspectJ)
--
Note that posts from new members are moderated - please be patient with your
first post.
---
You received this message because you are subscribed to the Google Groups
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/clojurescript.
