Hi Daniel, I am using 0.8-beta1.
I don't know exactly what the root cause is, but I suspect it is caused by passing in reified components (as oppose to vars) into the app-state which has never sat well, but I can't explain why as that is (AFAICS) exactly what React does. I will keep digging until I can get a reproducible case. On Thursday, 4 December 2014 12:59:25 UTC, Daniel Kersten 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.
