Thinking this through a bit more (why hasn't somebody written a "delay-submission-whilst-the-<talk-to-the-duck>-effect-takes-place" browser plugin yet?), this is part of a bigger question about om's app-state and the UI system-of-record.
I am treating the app-state as *the* system-of-record, not just as the knowledge the UI needs to function. Changes to this system-of-record are of more interest then the user entering data into the UI for example, even if they are functionally equivalent. In addition, "Controllers" are much less a 1st class citizen as the app-state is starting to act like a communication channel. Things happen in response to changes in the app-state. It will be interesting to see how scalable this approach is or whether "Controllers" end up being justified... 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.
