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.
