Re: Om book, I think it's still a bit too early since the idioms and best practices are still largely being figured out. A crowd sourced book that can be quickly updated as Om gets more and more battle tested could work, but for now I think contributing to the official docs and tutorials to bring (and keep) them up to date would be of greater value for now.
On Fri, 7 Nov 2014 11:31 Colin Yates <[email protected]> wrote: > On hindsight, I think my question is based on an incorrect assumption. In > a test case, whether you construct the data "on the fly" or map directly to > app-state the same number of "render" calls are made, so move on please, > nothing to see here :). > > On Wednesday, 5 November 2014 13:38:46 UTC, Colin Yates 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.
