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.
