Staying tuned ! I'm not in SF, will there be slides or videos ?
> Le 27 mars 2015 à 20:16, Marc Fawzi <[email protected]> a écrit : > > > You can have your cake and eat it. > > Will present the complete approach on the next Reagent meetup in SF, and > while we are talking about having a presentation about re-frame port of > ANgular's phonecat example, the reusable "smart" components presentation will > be based on RAW Reagent, nothing added. > > Stay tuned. > > >> On Fri, Mar 27, 2015 at 10:58 AM, Khalid Jebbari <[email protected]> >> wrote: >> If this approach suits you better, fine. Remember, this approach is coming >> from the React.js world, where everything is mutable and where there's no >> committment to a particular way of passing data/events. For my current >> projects, we indeed encapsulated both markup and behaviour, but it was hard >> sometimes to make it reusable without changing/hacking it. We didn't use a >> global method for sharing state like Flux, so it may explain why. >> >> >> >> Khalid aka DjebbZ >> @Dj3bbZ >> >>> On Fri, Mar 27, 2015 at 6:45 PM, Daniel Kersten <[email protected]> wrote: >>> 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 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 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.
