On Tue, Jan 21, 2014 at 9:14 PM, kovas boguta <kovas.bog...@gmail.com>wrote:
> I understand all these mechanisms exist for a reason, but is there > hope for simplifying things? > > The distinctions between :init-state and :state, and between :opts and > get-shared are pretty subtle. Additionally, there is also the vanilla > cljs way of defining constant global data, which people will think > about reaching for. > :init-state is an optimization and not strictly necessary. :opts is useful. om.core/get-shared leaves the door open for components requesting some global service without resorting to cljs.core/exists?. > Point 1: the pathways to access the local state are very limited in > Om, and seem likely to lead to complexity. For instance, passing data > into the parent so that it can set the state of its child. Or having > to manage channels to read/write to the local state via go loops on > the owner. > > Unlike OO/React, there is no object graph to navigate in order to get > access to the local state of some component. I fear for my render > functions, if they have to be conduits for some deep subcomponent's > local state update. > Not true. React has exactly the same problem. There's no public way to get at component state deep in the render tree. > Point 2: The APIs for app-state and local state are completely > different, for ideas that are not that much different. They are both > data for the pure rendering function; data which we want to be able to > update from both within the component and from above it. > application state and component local state are very different with respect to consistency. In principle, view-model data need not be much different from > app-state data; the differences are: a) it cannot be co-located with > app-state data, not because of clutter, but because there might be > more than 1 component built from the same cursor position; and b) it > needs to be initialized as the components are initialized. > It should not be co-located if it is not something you intend to snapshot. > There is no requirement that the view-model data be encapsulated in > the component, or even that packets of view-model data correspond > 1-to-1 with components. (One of the awesome things about Om is that > the app-state data can be relatively freely reshaped into components, > rather than the rigid 1-to-1 mapping in traditional MVC) > > Given these requirements, I think there is an alternative design, > though the margin is too small to contain it. Definitely open to alternate ideas but I won't budge on the fundamental split: a) application state b) component local state c) side information I do think that that being to able force a child component to write it's state into a) instead of b) is an interesting direction to pursue and perhaps can shed some light on how a) and b) can conceptually unified. David -- 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 clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
