FWIW I think the need for transformers will be significantly diminished when Om improves the component independence story as I've said earlier.
On Sunday, March 30, 2014, Rob Knight <[email protected]> wrote: > 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] <javascript:;>. > To post to this group, send email to > [email protected]<javascript:;> > . > 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.
