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. Besides the number of not-totally-orthogonal constructs, the use of local state makes me uneasy. 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. 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. In reality, our usage of the term "local state" is putting the cart before the horse. What we are really talking about is view-model data; that it might be implemented as "local state" is technology-technology to manage the additional information. 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. 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. -- 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.
