Since the data you want to change is the app-state, the simplest (and most
Om-like) thing to do is to have choice transact! or update! the data
directly. This may require you to make each choice a map or vector (rather
than eg a boolean) so that it remains a cursor:
(def app-state (atom {:poll-choices [{:selected? false}]))
(defn PollView [data]
(reify
om/IRender
(render [_]
(build-all choice (:poll-choices data)))))
(defn choice [data]
...
(dom/div {:onClick (fn [] (om/update! data :selected? true))}))
This is, after all, what cursor are for!
"On choice (defn choice [data, owner]) the first argument is obviously a
data row taken from the app-state. The second argument the owner, so the
Pollview - right?"
No - owner is perhaps a confusing name. It's the "react owner" of your Om
component, NOT the "Om owner" (or parent).
That is, owner is the actual react component that backs (and therefore
"owns") the Om component. Essentially, it IS the component itself (and if
you look at it in a debugger you'll see that it contains the components
lifecycle state, local state, props (which contain the cursor), id, react
key, etc etc).
There is no way that I know of to access the parent Om component from a
child Om component without passing it in yourself (or resorting to hackery
by accessing internal data since Om does track parents for it's own
internal use. But this is probably an implementation detail you can't rely
in).
Most communication is typically done through cursors. The rest is commonly
done through callbacks or core.async channels.
On Mon, 8 Dec 2014 08:05 David Mohl <[email protected]> wrote:
> Hey guys
>
> I am fairly new with OM and clojurescript and run into a case where I
> don’t know the ‘correct’ way of handling it.
>
> Following example:
> Pollview (react component) builds multiple choices through (build-all). If
> the user clicks on one of these choices, a ajax request gets fired, the
> users choice added and the component refreshed.
>
> Poll uses something like this:
> (om/build-all choice (vec (get-in app [:data :choices] nil)))
>
> On choice (defn choice [data, owner]) the first argument is obviously a
> data row taken from the app-state. The second argument the owner, so the
> Pollview - right?
>
> Once choice does the ajax request, it needs to communicate back to the
> pollview that something has changed and either force a refresh or simply
> change the app-state itself. But how do I reference back to it? Data is
> fetched inside the (will-mount) of the pollview. Can I somehow re-mount the
> entire view and force a rebuild?
>
> What I did, after having no success with the ‘owner’ argument, I simply
> passed the app-state cursor as options, but that feels very dirty to me:
> (om/build-all choice (vec (get-in app [:data :choices] nil)) {:opts
> {:app app}}).
> Choice is now using the cursor to directly replace the old data with new
> one.
>
> What is the proper ‘om’ way to handle this?
>
> — David Mohl
>
> --
> 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.
>
--
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.
