Thanks David. On Thursday, 6 November 2014 14:27:23 UTC, David Nolen wrote: > Most of the conundrums are obviated by reference cursors. Organize > your data however you like, only want needs to be re-rendered will be > re-rendered. > > On Wed, Nov 5, 2014 at 8:38 AM, Colin Yates <[email protected]> wrote: > > Hi, > > > > Another question of idiomatic usage (will somebody *please* right a > > "JoyOfClojure" type book about om ;)). > > > > I have a hierarchy in my app-state (e.g. a hierarchy of locations). I also > > have app-state which stores the ids of the nodes that are selected > > {:reference {:locations {:id 1 :text "All locations" :children [...]}} :ui > > {:page-1 {:locations {:selected-ids []}}}}. > > > > However, for the purposes of this question let's assume I don't want to > > store the ids of the expanded nodes. > > > > My question is where to store this state: > > > > [tree local state in an expanded-ids []] > > If I do this (i.e. the tree's IInitState returns {:expanded-ids []}). Each > > component node in the tree is passed {:expanded? (id-in? (:id node) > > expanded-ids). Every time I expand or collapse the tree the tree > > component's top-level state (i.e. the expanded-ids vector) is changed which > > causes the whole tree to re-render. > > > > [tree local state in a projected-tree] > > In this scenario the component state is a hierarchy that merges the > > underlying (e.g. locations) tree with an "expanded?": {:id 1 :text "All > > locations" :children [...] :expanded? bool). As before, each tree node is > > now mapped to an individual node however, expanding or collapsing the tree > > only changes the data that a specific node is referencing so only that node > > needs to be re-rendered? > > > > [no local state] > > In this scenario there is no local state and it all comes from the > > app-state. This is actually a red herring as the question is the same - > > what data structure do you store? > > > > In both scenarios the same amount of dom manipulation is done due to om's > > optimisations and react's fantastic diff engine, but in the first the whole > > component is re-rendered, in the second only the individual node is > > re-rendered. > > > > It would seem that the second approach is the way to go, the more expensive > > the rendering the truer this is, except it has an additional complexity of > > wrangling together a bunch of data structures (as well as expanded there > > might be many more). > > > > Firstly, are my assumptions correct (they seem to be based on my initial > > investigations) and secondly, what do you all do? > > > > (Has anyone thought of writing a book on this stuff? I can't be the only > > person who has been doing this a while and been completely blown out of the > > water by the whole "treat the dom like a projection/state-machine/pure > > function" mind set?) > > > > -- > > 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.
