What does work is adding the call in the (render) method of the form-component
itself.
To be clear:
(defn form-component [form owner]
(render ...
(logic-that-processes-the-whole-form form)
(om/build input-1 ..)
(om/build input-2 ..)
(om/build input-3 ..)))
This is a perfect fit in this case as the data
logic-that-processes-the-whole-form needs is a subset of the data the component
needs.
It is also very nice as it fits in with the lifecycle and doesn't care where
the data came from (the UI or the DB). It does feel a bit co-incidental though
that the render lifecycle happens to be symmetrical with
logic-that-processes-the-whole-form's.)
This approach wouldn't work if either:
- it requires data that the component doesn't
- it needs to act on un-committed data (e.g. if it required some
transient/component state in one of the nested components)
I think this subject is best served with a blog post or two and some github
examples, so if nobody responds then this thread can die. If I ever find the
time to do a blog post justice I will post the link here :).
On Monday, 12 January 2015 10:37:56 UTC, Colin Yates wrote:
> 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.
