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.
