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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/clojurescript.
