> > 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.
