Ps I didn't read your code carefully due to lack of time, so I'm not sure if what I said is the root of your problem. But it's worth checking.
On Thu, 4 Dec 2014 12:59 Daniel Kersten <[email protected]> wrote: > Are you using the very latest Om? Older Om's did not support anonymous > functions and multimethods. Its meant to support it for last few releases > although I still had issues last time I tried. I noticed that David added > some sort of tweak or fix specifically for multimethods in the latest > version, so I would try that. > > The reason I mention this is because unmounting and remounting is exactly > the behavior I've seen with this. I've also seen this behavior when > changing opts between renders (although this may have been caused by > something else as in a minimal test changing opts was simply not seen by > the component). > > The react-key "fixes" it because you're telling react that it's the same > component so please don't unmount, but I would try to fix the root problem. > > > > On Thu, 4 Dec 2014 12:29 Colin Yates <[email protected]> wrote: > >> I have isolated the code in question and it was written very early on >> (e.g. woooh, here be dragons :)): >> >> Essentially I have a component which calls a multimethod to render a >> child. This is the implementation of that multimethod. This itself uses a >> common component and passes in components to that common component. >> >> Adding a key to the returned component (that isn't a keyword but a >> string(!)) gives React enough help so it doesn't unmount it. >> >> For clarity, filter-header simply displays a nice formatted title and >> puts "main-component" into the body. >> >> [code] >> (defmethod layout/render-right-component ::consultant >> [{:keys [owner data]}] >> (om/build >> c/filter-header >> {:id :consultants >> :main-component >> (om/build >> tree/bound-tree >> nil >> {:fn (fn [_] {:nodes (om/observe owner (state/all-consultants)) >> :selected-ids (-> data :filter :consultants >> :selected-ids) >> :expanded-ids (-> data :filter :consultants >> :expanded-ids) >> :local-search (-> data :filter :consultants >> :local-search)}) >> :opts {:change-fn >> #(search data true) >> }}) >> } >> ;; WITH THIS REACT NO LONGER UNMOUNTS >> {:react-key "Consultants"}) >> ) >> [/code] >> >> As to the reduced problem, I need to keep poking, and I still don't >> understand why it needs the "Consultants" key... >> >> This realising components in state (e.g. the :main-component) isn't doing >> it for me so I think I might utilise more multi-methods. The problem is >> always how to deliver the focused cursor into the defmethod (e.g. >> render-right-component really wants to take in the cursor at (:filter >> :consultants). But that is another experiment. >> >> Any advice is welcome. >> >> On Thursday, 4 December 2014 12:13:16 UTC, Lucas Bradstreet wrote: >> > > On 4 Dec 2014, at 20:02, Colin Yates <[email protected]> wrote: >> > > >> > > Hi Lucas, thanks for the info. >> > > >> > > You are right - I should have been clearer. My scenario is that the >> component hierarchy itself isn't changing only the app-state that the >> hierarchy is mapped to. >> > > >> > > In its simplest form, think of a combo-box. The app-state is {:text >> "" :results []}. The component has an input field mapped to :text and a >> <ol> mapped to :results. Changing :text populates :results accordingly. >> > > >> > > Your point about keys is worth investigating. Where I am setting keys >> (mainly on dynamic children) they aren't changing. I'm not setting them >> elsewhere though, which might be worth a look. >> > >> > Hmm. Maybe the lack of keys on some components may be the issue. >> Perhaps react can't assume that the components are the same and thus >> unmounts and remounts them (the dom diffing ensures this is still fast) e.g >> imagine an unordered list where a list item is inserted mid list. I haven't >> tested whether this is true. >> > >> > > >> > > Another clarity question - if an ancestor component is remounted does >> that cause all children to be remounted? It might be something much higher >> up in the hierarchy causing a remount... >> > > >> > >> > I would think so. Again, I haven't tested this. >> > >> > > Thanks for confirming my assumptions anyway, I will dig in a bit >> deeper. >> > >> > Please let us know the result. >> > >> > Cheers >> > > >> > >> On Thursday, 4 December 2014 11:39:44 UTC, Lucas Bradstreet wrote: >> > >> Hi, >> > >> >> > >> Changes to app state *can* cause components to be unmounted. Imagine >> a component that renders another component, if a boolean value in the app >> state is true, otherwise it renders and empty div. When the boolean changes >> from true to false and the component is re-rendered, the subcomponent will >> be unmounted. >> > >> >> > >> However, if the subcomponent should be re-rendered in both cases, it >> should not be unmounted. >> > >> >> > >> Thinking about it, you're probably mistakenly using a different >> react-key between the renders. This will cause a new component to be >> mounted as it is not treated as a continuation of the previous component. >> > >> >> > >> Lucas >> > >> >> > >> >> > >>> On 4 Dec 2014, at 19:29, Colin Yates <[email protected]> wrote: >> > >>> >> > >>> Hi all, >> > >>> >> > >>> I am seeing a component consistently unmount/remount every time the >> application state changes. If I change the local state instead then it >> doesn't umount but simply re-renders as I expected. >> > >>> >> > >>> I didn't expect changes in app-state to cause an unmount/remount >> only a re-render (as that is my understanding of React's lifecycle). >> Further, since I am talking about this my assumption (and the behaviour I >> am seeing) is that om will only call the render protocol method if the >> values have actually changed. >> > >>> >> > >>> If my assumptions are correct I will see if I can reduce the >> problem into a simple gist. >> > >>> >> > >>> The reason this is a pain, performance aside, is because a re-mount >> loses focus and this specific component is a text field. I notice in the >> discussion on text-fields in the Basic tutorial "text" is component local, >> maybe now I understand why as this seemed to me to go against the grain of >> what is advised to go into local state... >> > >>> >> > >>> Can somebody please clarify? >> > >>> >> > >>> Thanks! >> > >>> >> > >>> -- >> > >>> 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.
