That is interesting, but doesn't the model where components declare what data they fail in cases where the decision of which component to display is driven by the data? In other ways, it may satisfy 98% of all scenarios but fail when the UI is not only data driven but data generated.
On Sat, Jan 31, 2015 at 9:52 PM, Dave Sann <[email protected]> wrote: > Marc, > > I believe that the core idea is that to component specifies the data it > needs - via a query (this is static). This is then composed up the > hierarchy to generate the overall data query and to ensure that data passed > back down the hierarchy contains required data in the required structure. > > The aim is to stop cascading code changes in nested components when data > needs change. > > They also suggest that these definitions of required data can allow global > optimisation of what data is fetched when. > > I think that these are interesting ideas and may have wider applicability > > Dave > > -- > 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.
