Yes, dumb components don't encapsulate beahvior. Indeed if you generic
behaviour you need as someone proposed to push a generic event, and the app
handles it specifically.
Khalid aka DjebbZ
@Dj3bbZ
On Fri, Mar 27, 2015 at 4:45 PM, Jamie Orchard-Hays <jamie...@gmail.com>
wrote:
> Good articles. Thanks, Mike. In my apps I think of them as "generic" and
> "specific", or something like that. IOW, I want some generic views that are
> dumb and know nothing about the app and can be used where ever I need them.
> They get composed into specific views.
>
> Jamie
>
>
> On Mar 27, 2015, at 10:12 AM, Mike Thompson <m.l.thompson...@gmail.com>
> wrote:
>
> > On Saturday, March 28, 2015 at 12:58:17 AM UTC+11, Khalid Jebbari 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.
> >
> >
> > I'm not sure how much this perspective applies to the Clojurescript
> wrappings, but here are further references:
> > https://medium.com/@learnreact/container-components-c0e67432e005
> > https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0
> >
> > --
> > 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 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 a topic in the
> Google Groups "ClojureScript" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojurescript/WOGdUY79Xv4/unsubscribe.
> To unsubscribe from this group and all its topics, 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.
