I didn't so much mean that the data should be hidden (I think that not hiding it is definitely desirable and in my example keeping the editing of the data separate from managing what data (existing vs new blank slate) is to be edited is most definitely a good thing), but rather removing the need for the parent to know too much about it unless it needs to - I'm also thinking in terms of separation of concerns.
My *use case* is in terms of higher order components where I can, for example, pass a widget into a table component or tab component or something like that and the table component shouldn't need to know anything about the widget being passed in. I will experiment with it though and see what works well for me and will let the list know what I find :) On 21 April 2014 13:28, David Nolen <[email protected]> wrote: > 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. > -- 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.
