UI perf – render tree pruning, reactions, indexer/reconciler, and incremental rendering

UI perf – render tree pruning, reactions, indexer/reconciler, and incremental rendering

This is a brain dump as my thoughts are quite jumbled right now.

If I define a UI as just functions, no React components or Reagent components, is it possible to layer render-tree pruning on top of this, or index and reconcile this somehow? For example a macro that walked the tree and injected React components at the right places. Memoizing each function comes to mind as well. We want to run the macro at only the runtime/root (outside of UI code) such that UI code is nothing but functions, no dependencies.

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? (See A Rant on Om Next for an amazing debate) 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. 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?

Another perhaps optimal approach is to code the UI in continuation-passing style (or write a macro to compile the ast into cps), so that instead of forceUpdate, we just "rewind and resume" like a debugger? This sounds very promising

Submitted June 23, 2017 at 05:19PM by dustingetz
via reddit http://ift.tt/2s2ZFP3

[Help] Creating a schedule program from a YAML file.

[Help] Creating a schedule program from a YAML file.

Hi follow Clojurians,

Learning Clojure for a few weeks now and thought that since I'm going to a convention in several days I'd make a program to display the rough schedule of the panels I'd like to attend.

Been learning Clojure via Clojure for the Brave and True and there was a little application where we parsed each entry in a .csv file to print them out in a vector of maps. Here's the code from the book:

Screenshot 1

Screenshot 2

And then here's the YAML file.

My question is if it's possible to use similar functions from the code the book gave, and if so how different would those functions need to be since I'm dealing with a YAML file and not a CSV file?

Submitted June 23, 2017 at 06:30AM by ProfessorSexyTime
via reddit http://ift.tt/2t0LyOY