If it's data-dependent, then I don't see any reason to pass components down the tree. You just look at the data and decide, based on the data, what you're showing in the Header.
It seems like you're dealing with different pages or different views. If needed, perhaps you have some local state you set on the component that contains the Header component. The container sets the Header's local state to whatever sort of summary is needed. As you and David mentioned, multi-methods might be useful in terms of simplifying the code. Jamie On Nov 18, 2014, at 11:14 AM, Colin Yates <[email protected]> wrote: > Hi Jamie, > > It could (and probably will) be. > > In my example, the Header component is the generic component but it might > display a summary of the table being displayed elsewhere: > > --------------------------------------- > - HeaderComponent "Displaying 10/1000" > --------------------------------------- > - TableComponent > --------------------------------------- > > where "Displaying 10/1000" is the summary of the same data TableComponent is > using. > > On the other hand, an "add screen" might look like: > > --------------------------------------- > - HeaderComponent "Please fill in X" > --------------------------------------- > - FormComponent > --------------------------------------- > > and so on. > > Other times the HeaderComponent won't have anything to display. > > This is obviously just a hoicky example though. > > > On Tuesday, 18 November 2014 15:15:20 UTC, Jamie Orchard-Hays wrote: >> Colin, is the optionally displayed component dependent on the data? >> >> >> On Nov 18, 2014, at 5:24 AM, Colin Yates <[email protected]> wrote: >> >>> The reason I have shied away from multimethods is that they aren't local to >>> the current namespace (which is the point I guess :)), and I tend to end up >>> 'using' each namespace which declares a defmethod. >>> >>> For example, if I have a common/navbar which declares a defmulti say-hello, >>> in >>> page-1 I defmethod say-hello .. "page-1". In page-2 I do the same. The >>> problem is that I end up with a main namespace which uses both page-1 and >>> page-2 so when page-1 calls common/navbar the defmethod in page-2 is the >>> one that takes precedence. >>> >>> I could pass in a qualifier to navbar which is used as part of the >>> dispatching logic I guess (so page-1's qualifier is :page-1 etc.). >>> >>> How do you solve this? >>> >>> On Monday, 17 November 2014 12:52:44 UTC, David Nolen wrote: >>>> I would leverage multimethods. However nothing prevents you from >>>> composing components and passing them via props - this approach is >>>> popular in React. >>>> >>>> David >>>> >>>> On Mon, Nov 17, 2014 at 6:49 AM, Colin Yates <[email protected]> wrote: >>>>> Hi all, >>>>> >>>>> I keep running into the really common use case (and seeing others running >>>>> into as well) of composing components. >>>>> >>>>> Quite simply, how is one supposed to compose components in om? >>>>> >>>>> In my particular use case I have a Header component which displays a >>>>> title and optionally a component describing a summary of what is being >>>>> seen (which is more than simple text). I want to do something like: >>>>> >>>>> (defn header [data owner] >>>>> (reify >>>>> om/IRender >>>>> (render [_] >>>>> (dom/div ..... >>>>> (when optional-component) optional-component))))) >>>>> >>>>> It works if I put the component into either the header state or opts (e.g. >>>>> (header data owner {:opts {:optional-component (om/build ...}})) >>>>> >>>>> but neither feel idiomatic. If I had to chose the lesser of two evils I >>>>> would chose :opts I guess. >>>>> >>>>> I did consider multi-methods, but this didn't feel particularly nice >>>>> either. >>>>> >>>>> What am I missing as this doesn't seem to be an obscure use-case :)? >>>>> >>>>> -- >>>>> 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. -- 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.
