Here's an attempt to outline some categories of Om data and their characteristics -
1. Computed data. Read only, not subject to direct "update". N.b. get-in qualifies as a computation; constant data is a degenerate case. It can be argued, on the grounds of programmer convenience, performance, or architectural simplicity, that constant data should be split off into a separate case. However it has the characteristics just outlined. 2. Model data. Can be read, and directly updated. 3. Default data. This is a combination of 1 & 2. It is computed initially, but is subject to direct update. After direct update, its characteristics are identical to model data. After initial computation, there are 2 possibilities: A) promote default data to model data immediately after the initial computation B) promote default data to model data upon first direct update. The difference is that in flavor B), the value of the default may continue to vary, as inputs to the default computation vary - this exactly how computed data works. They continue to be linked. In flavor A), the default is computed once, and if the data that was the input to the computation changes, it has no effect an the already-generated default data. Flavor A shares this characteristic with the current scheme for local state. An example where flavor B might be useful: setting the default font size for a list of notes, based on variable global parameters. You want to explicetly set the font size for one note, while letting all the others continue with default behavior. There are some more axis along which we can analyze the categories of data, such as visibility, lifecycle & time-of-update, etc. On Tue, Jan 21, 2014 at 8: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. > > 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 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.
