Conrad,
Your understanding is mostly right, with the exception of :opts. :opts is
just a modular way to push side information down the render tree -
information that doesn't belong in application state, nor component locate
state. :opts can in fact change and perhaps people will find that useful.
However, most of the uses of :opts I've seen can and probably should be
replaced with :init-state and :state usage instead.
One thing you didn't mention is om.core/get-shared. Setting shared data via
om.core/root + om.core/get-shared allows shared values across the entire
render tree that will never change.
David
On Tue, Jan 21, 2014 at 3:43 PM, Conrad Barski <drc...@gmail.com> wrote:
> Hi everyone, there are now four different ways to pass data from
> parent->child components in the build function defined in the 0.2.3 library:
>
> - Via the cursor
> - Via the optional map, using on of three different map keys:
> :init-state
> :state
> :opts
>
> Let me take a stab to see if I can explain the difference between these
> four, and if anyone knows if this explanation is flawed, let me know.
>
> Let's assume we're buying socks through a web store:
>
> If the data passed to the child is part of the main application state, we
> do it via the cursor. For instance, our application state might contain the
> fact that we've put two pairs of red socks into our shopping cart. If we're
> rendering a component for each item in our shopping cart, the item for the
> red socks would get passed a cursor into the main application state that
> ends up pointing to a branch in this state containing something like
> {:item_id 32423 :amount 2 :desc "Red Socks"}
>
> If the component has to maintain some transient state and this transient
> state has a default value, we set it via :init-state. For instance, if the
> customer tries to purchase their socks, we might display a "shipping
> address" component, with a "submit" button. But on top there might be a
> checkbox called "Same as billing address" that is checked by default.
> Therefore the component managing the checkbox might be given an :init-state
> of {:same-as-billing true} which establishes this default state. If React
> then decides to re-render this component, the :init-state in the re-render
> will be ignored. Also, since the user hasn't hit the "submit" button yet,
> we want to keep this state local instead of polluting our application state
> (which is why we didn't use the cursor.)
>
> The :state option is used to merge new state information into the child
> component, triggered by the parent. For instance, if the "shipping address"
> component is already visible, but the user has decided via another Om
> component that they want to pay with bitcoin, the root application state
> may now have a new key set inside it of {:payment-method :bitcoin} which
> will trigger a rerender of the root component. As part of that, the parent
> component would now set the :state key the "shipping address" component of
> {:billing-address-available false} so that the "Same as billing address"
> checkbox is disabled (since a bitcoin payment is pseudonymous and has no
> physical address.)
>
> Finally, if a component needs to be passed a value that will never change
> through the lifetime of the component, we do it by passing in :opts. For
> instance, our web store might have a component called "fine-print", that's
> instantiated in different parts of the store to display some
> context-appropriate legalese. Since the text in this component may be
> different in different parts of the store, but remains constant through the
> life span of a given component, we can pass in the string of legal text via
> :opts.
>
> Anyway, I'd love to hear anybody's opinions as to whether this description
> matches the behavior and intention of the latest Om changes.
>
> --
> 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.
>
--
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.
