Marc, can you tell us a little more about the approach your taking?

On Fri, 27 Mar 2015 at 17:43 Marc Fawzi <[email protected]> wrote:

> Yeah but then what are you really reusing? I have components that have
> sophisticated behavior... sharing just the markup and styles is of limited
> value since what I want to share in effect is the smart components, which
> is why I had settled on components encapsulating behavior as a pattern...
> works better for me to share the whole component (with its behavior) rather
> than just the dumb part....
>
> On Fri, Mar 27, 2015 at 10:25 AM, Khalid Jebbari <[email protected]
> > wrote:
>
>> 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 <[email protected]>
>> 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 <[email protected]>
>>> 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 <[email protected]>
>>> 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 [email protected].
>>> >>>> To post to this group, send email to [email protected]
>>> .
>>> >>>> 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 [email protected].
>>> > To post to this group, send email to [email protected].
>>> > 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
>>> [email protected].
>>> To post to this group, send email to [email protected].
>>> 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 [email protected].
>> To post to this group, send email to [email protected].
>> 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 [email protected].
> To post to this group, send email to [email protected].
> 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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/clojurescript.

Reply via email to