Hi Jamie - thanks for your thoughts. I don't think this will work as the first time the user makes a selection the non-default state is the default-state + the user's selection.
I am also not sure how the component sees the latest set of default-values, unless default-value is itself a subscription. I may not have been clear, but at any point in time I need to know what the state is, maybe hours before the component is rendered. On 20 April 2015 at 20:02, Jamie Orchard-Hays <[email protected]> wrote: > My first thought is the Component would have local state with your default > value. If a non-default value is passed to your C, then it's used instead. > > (or passed-in-value default-value) > > The default is clearly based on the data passed into the tree, which agains > suggests a local state. The default is based on the data the tree C is given. > > So, you end up with a local default (an atom) that is set based on the data > when the component is mounted (:component-will-mount). > > Then when the tree C's state display state has changed, you update local > state so as to ignore that default that was set during (I'm guessing > :component-will-update) > > HTH > > Jamie > > On Apr 20, 2015, at 2:52 PM, Colin Yates <[email protected]> wrote: > >> Hi, >> >> This is somewhat reframe specific, but how do people handle default-values >> that can change? My specific use-case is that I have a tree which can be >> expanded and collapsed. By default the tree should be expanded to a certain >> level, however, as soon as the user manually expands or collapses a node >> they should no longer follow the default. The data the tree is displaying >> can change, meaning the defaults can change over time. >> >> I can't simply define the defaults on startup because the defaults will >> change over time. >> >> It can't be a subscription because the values need to be available in the >> handler. >> >> My current thinking is that the app-db state has a 'follow-defaults?' which >> is true by default but is set to false when the user explicitly changes the >> state (e.g. by expanding or collapsing). When the underlying hierarchy >> changes from the server, propagate that change to all of the parts of the >> app-state that are interested. >> >> To be explicit, imagine I have the following template for tree: >> {:expanded-ids [] :follow-defaults? true}. There are 6 instances of this >> template in the app-db (i.e. 6 distinct UI trees). When the server informs >> the client that the source-data has changed it then updates each instance >> where follow-defaults?. >> >> I understand the rationale as to why subscriptions can't be in the handlers >> but a subscription which switches on follow-defaults? seems ideal. >> >> Maybe I could hack a UI-less component which reacts to that subscription >> change by directly updating the underlying db... >> >> What would you all do? >> >> -- >> 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.
