On Sunday, 30 March 2014 05:23:32 UTC+1, Daniel Bell wrote: > Man, I must just be failing really hard at describing this. transact! does > take a cursor; the issue I'm struggling with is: in the context of an event > handler, where does the destined-for-transact cursor come from?
In om/build, your component is given a cursor into the application state, which might be quite deep within the overall app state. Your component doesn't need to know anything about the surrounding app state, just the part pointed to by the cursor - as far as the component is concerned, the cursor it is given is the "root". You can see this in the basic example, looking at the different between contacts-view, which is given the top-level app state in the om/root call, and contact-view, which is given (:contacts app) in the om/build-all call. Your component must be able to understand the structure of the app state that it has been given in order to be able to render something from it. If the cursor points to a vector of maps with fields called :name and :phone-number, your render function is going to need to know those keywords. By design, your component should only be modifying state that's pointed to by the cursor it was given, and it doesn't require any more knowledge to be able to call transact! on the cursor than it does to pull data from the cursor for rendering. So, this might be problematic if you have two components, written by different authors, that want the app state to look similar but slightly different. Say one expects :telephone-number instead of :phone-number. This is a genuine problem, but using channels in event handlers doesn't solve it because the same problem would apply during rendering. I think this is what Sean is trying to solve with 'transformers'. > You can hard-code a key-sequence in your component definition but that makes > your component not really reuseable; you can pass it in to the build call for > the component, but often that build call takes place in the definition of > another component, so now you've just moved the unreuseability up a layer. > Alternately you can mirror the structure of the component hierarchy in your > application state, but now you're (at high risk of) complecting state and its > representation. > > I suspect that I just need to play around more with higher-order components. > The fact that Om components are functions makes a lot of things possible. -- 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.
