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.
