On Friday, March 27, 2015 at 11:54:16 PM UTC+11, Colin Yates wrote:
> In re-frame event dispatching is handled by (dispatch [:discriminator
> detail]). A corresponding (register-handler :discriminator (fn [db [_
> detail]]) then reacts to that dispatched event.
>
> My question is how are people managing this with re-usable components? For
> example, I have a tree and when selecting a node in that tree something
> should happen. But this is where it gets all polymorphic as _what_ happens
> depends on the client who instantiated the tree. I can see the following ways
> forward:
>
> - tree is configured with a 'context' key which is combined with the
> discriminator so rather than the tree emitting :node-selected it emits
> :consumer-a-node-selected. Consumer a can then handle
> consumer-a-node-selected and consumer b can handle (go on, guess)
> consumer-b-node-selected
> - a variation on the above involving writing your own dispatching logic...
> - tree doesn't use dispatch as the event bus, rather it takes in an instance
> of a Protocol:
> IRespondToTree
> (on-node-select [this node])
> - tree is parameterised with a map of fns {:node-selected-fn ...} etc.
>
> How would you all handle it? (I am leaning towards the first one).
None of our reusable components know about re-frame. None of them dispatch
directly. That's the job of the application specific code using both re-frame
and re-com (our reusable component library).
Instead, our (re-com) reusable components are given (by the app) on-click
callbacks, or on-change callbacks, etc. And these callbacks are often called
back with an identifier (what got clicked, or what changed).
When the app creates the component, it supplies these callbacks, and organises
for the callback to do the dispatch. The app creates the glue between the
libraries.
Here's an example (we use named parameters):
[radio-button
:model some-subscription-val ;; the currently selected value in
the button group
:value "green"
:label "make it green"
:on-change (fn [val] (dispatch [:set-colour val])]
Notice that the reusable component “radio-button” doesn't dispatch itself. It
just calls back to a passed callback, which the app code creates (and which
happens to dispatch). So the app code itself is the glue between the reusable
components and re-frame.
In your case, with a tree, I'd imagine something like this sketch:
Your reusable component requires the tree be specified in a certain way. Eg:
Each node has an "id", "a label" and, optionally, "children".
(def tree-data
[ {:id 1 :label "item 1" :children [{:id "me" :label "me"}
{:id "them" :label "not me"}
]}
{:id 2 :label "item 2" :children [{:id :sub1 :label "sub1"}
{:id :sub2 :label "sub2"}
]}]):
Then you'd have a tree component which an app can use like this:
[tree
:nodes tree-data
:on-click (fn [id] (dispatch [:node-clicked id]))]
Notice how the component calls back with the :id of the clicked item. (Supplied
by you in the tree-data structure).
--
Mike
--
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.
