That's really jumping. I can hardly follow that. Maybe we can talk about it here http://clojureverse.org/
On Fri, Jun 23, 2017 at 6:16 PM Dustin Getz <[email protected]> wrote: > Basically dumping my brain here as it is quite jumbled, > > Walking the ui ast and injecting memoizers is an incomplete solution, it > will yield render-tree pruning, but it is understood that render-tree > pruning will not work with graph values. Walking the ui ast to inject thick > components (that can be forceUpdated) is still a candidate in my mind. > > The way an indexer/reconciler works (in both Om Next, and in Reagent) i > believe, you want each horizontal layer in the UI tree responsible for > connecting to his own dependencies. Reagent tracks reaction derefs to imply > the connection between instance and dependency; om next provides the query > protocol and uses that to connect the instance to its dependency. The > approaches are more or less equivalent, right? Either way, each strata in > the tree is managed standalone and forceUpdated out of band. > > Any forceUpdate approach will necessarily violate function laws like > dynamic scope, because we're perverting the evaluation rules of the AST to > evaluate breadth first instead of depth first? So even if we can write our > UI code as just functions, and use a macro to inject the components, the ui > as it evaluates is going to violate function laws. So i dont know if i see > a point to exploring this approach further, as the goal was to make UI code > evaluation follow the same proper laws as regular code evaluation. > > Another approach is to use incremental rendering as described in John > Degoes's talk on Purescript Halogen > <https://www.slideshare.net/jdegoes/halogen-past-present-and-future>. > Essentially, if react lets us define our UI :: state -> VirtualDom, > incremental lets us define ΔUI :: Δstate -> ΔVirtualDom, and the runtime > provides UI=reduce(ΔUI, Δstates) where Δstates is a stream of state > changes. This will give us all our laws and be fast and work with graph > values in state, but the types involved are complex. Incremental also loses > the intuitive nature of react though where it feels like we are defining > html templates. Thinking in terms of Δhtml templates, i dont even know what > that would make the ui code look like, probably something like redux > reducers. But it would be correct and optimal performance? > > -- > Note that posts from new members are moderated - please be patient with > your first post. > --- > You received this message because you are subscribed to a topic in the > Google Groups "ClojureScript" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojurescript/Fy-8QmJuv80/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://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 https://groups.google.com/group/clojurescript.
