Khalid,
I read about that on some blog post (dumb and smart component) but I'm
afraid that dumb components in this case will be truly dumb and offer
little benefit for them to be shared (what is worth reusing/sharing is the
behavior, markup and styles, not the markup and styles alone)
To make sure I'm getting what you're proposing, are you saying dumb
components don't encapsulate behavior? I think the same question applies in
case of what Jane describes.
On Fri, Mar 27, 2015 at 6:58 AM, Khalid Jebbari <khalid.jebb...@gmail.com>
wrote:
> On Friday, March 27, 2015 at 2:39:37 PM UTC+1, Jamie Orchard-Hays wrote:
> > Does it make sense to pass the reusable component's context as an
> argument to it? ie,
> >
> > (defn ReusableComponent [some-context] .... )
> >
> > Jamie
> >
> > On Mar 27, 2015, at 8:54 AM, Colin Yates <colin.ya...@gmail.com> 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).
> > >
> > > --
> > > 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.
>
> Not sure I'm going to answer the question directly, since I've never used
> re-frame, Reagent or Om. I'm just an experienced React.js developer VERY
> interested with Clojure(Script).
>
> If you want reusable components, whatever wrapper you use around React,
> here's the plan.
>
> You should create 2 types of components : dumb and smart. Dumb components
> do 2 simple things : display stuff and handle input/events. The way they
> handle should be agnostic to any kind of library and should use only
> language-level feature. Functions. So the dumb component use function it's
> been passed and call it with the input/event. The smart components wrap
> dumb components and connect to the outside world with whatever your stack
> uses (channels, events, ratoms, what not).
>
> This way your dumb components are always reusable, whatever stack/project
> they're incorporated in. They can also be displayed in a simple page for
> your graphics or HTML/CSS team to check their look. The smart components
> handle whatever logic you want to put in them. So from a stack/page/project
> to another, only the smart components change, no the dumb ones. This keep
> UI consistent and separate concerns.
>
> Hope it's clear and helpful.
>
> --
> 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.
