On Mon, Apr 21, 2014 at 8:20 AM, Daniel Kersten <[email protected]> wrote:
> The solution is, of course, to initialise the app state in the parent when > calling build (either by passing in a modified cursor, or using :state or > :fn options). > I find that in cases like my editor example, this breaks encapsulation > (but does give you a lot of flexibility by decoupling managing state from > using state). > Two options would be to either wrap the component in another "state > manager" component, or to wrap calls to build to make component-specific > build functions (eg build-my-widget would call om/build and correctly set > up the state/opts etc). > I don't really put much stock in the information hiding aspect of encapsulation. The existence of component local state in Om is primarily about a separation of concerns - not data hiding. > David - I see that om-sync uses an "invisible" component. Its my > understanding that using invisible components to manage state is how you > expect state to be accessed by "external" things, as in om-sync, but how > expensive are they for internal things where other solutions (like wrapping > build) also exist? IE which, in your opinion, should be the preferred > approach? > I haven't played around with Om myself enough to say what I think the preferred approach is. Try some things out and see what works, write about it somewhere :) -- 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.
