Om's current API more or less follows this line of thinking - components are machines. However both the opaque nature of machines and the lack of fine grained control around immutable value storage (app state wrapped in an atom) have their downsides. I want Om components to have knobs. So while a component designer may decide to split their state in a certain fashion - users of the components should be able to reconfigure this without the system falling apart.
On Thu, Jan 23, 2014 at 12:57 PM, Brandon Bloom <[email protected]>wrote: > > > Not true. React has exactly the same problem. There's no public way to > get > > > at component state deep in the render tree. > > > > Fair enough. I'm still in the "local state is poison" camp though. > > To be fair, React really doesn't implement component state as "local > state". Such a thing can't exist because components are virtualized objects > which are only hydrated when they need to do computation. The > implementation utilizes a global state map, precisely because such local > state is poison: It's what necessitates "removeChild" and "dispose" > mechanisms in other UI frameworks (essentially reference counting). > > The two distinctions relevant to component state are between 1) > encapsulated and exposed state and 2) durable and ephemeral state. > > React's state model provides components with encapsulated, emphemeral > state. Encapsulated meaning that other components can't reach in there and > tinker with it. Ephemeral meaning it isn't permitted to be captured to be > stored and if it is somehow lost, it's not a big deal because it can be > recovered. > > The ephemeral nature of the data is somewhat intrinsic because the DOM is > ephemeral: If you were to serialize your application and teleport it to > another browser, you'd have to rebuild/recover the DOM's state. There is > much DOM state that shouldn't be ephemeral, but we're stuck with it. > However, there is much model/view state that should be ephemeral and we > need that option. > > I'll quote Rich on encapsulation: "[If] you have a notion of “private”, > you need corresponding notions of privilege and trust." The fact that > components are encapsulated is part of what makes larger apps even > possible. It's the wrong default for values, but it's the right default for > "machines" (which components are). With values, we can get > pseudo-encapsulation with a deftype wrapper. With machines, we can get > unencapsulation by other means... but that's a larger topic I won't go in > to unless prompted. > > I haven't kept up with Om's API evolution, so I can't comment on how this > line of thinking can/should influence the design, but hopefully thinking > about these properties is useful. > > -- > 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.
