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 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.
