Optimizing virtual dom computation without using React

[Dustin Getz]

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.

[Jiyin Yiyong]

I tried something like that. Actually I implemented a simple virtual DOM library by myself to do that. https://github.com/Respo/respo Since I'm not using React, I can optimize virtual DOM with  `identical?` function as I need, and let the library reuse existing components. It's possible, but I'm not sure if this is what you want.

[Dustin Getz]

I see very interesting. Is it technically feasible to only run the macro from one place, so usercode is just functions?

--
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 clojurescript+unsubscribe@googlegroups.com.
To post to this group, send email to clojur...@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.

[Dustin Getz]

Like this: https://stackoverflow.com/questions/3346382/clojure-adding-a-debug-trace-to-every-function-in-a-namespace

[jiyinyiyong]

I don't get your question. For Respo, if you mean macro, there's only one macro called `defcomp` I just added. Respo itself is built with functions. So a week before, my code was all functions, like this https://github.com/Cirru/stack-editor/blob/master/src/stack_editor/comp/container.cljs#L21

On Tue, Jun 13, 2017 at 6:12 PM Dustin Getz <dusti...@gmail.com> wrote:

I see very interesting. Is it technically feasible to only run the macro from one place, so usercode is just functions?

On Tue, Jun 13, 2017 at 12:42 PM, Jiyin Yiyong <jiyin...@gmail.com> wrote:

I tried something like that. Actually I implemented a simple virtual DOM library by myself to do that. https://github.com/Respo/respo Since I'm not using React, I can optimize virtual DOM with  `identical?` function as I need, and let the library reuse existing components. It's possible, but I'm not sure if this is what you want.

On Saturday, June 10, 2017 at 12:02:50 AM UTC+8, Dustin Getz wrote:

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.

--
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 clojurescrip...@googlegroups.com.

To post to this group, send email to clojur...@googlegroups.com.
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 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 clojurescrip...@googlegroups.com.

[Dustin Getz]

Respo UI code is all functions but many of the functions are wrapped in defcomp at the place of definition. Is it possible to move the defcomp up to the root of the UI, so UI code is just functions and no dependency on the macro?

[Dustin Getz]

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. 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?

[jiyinyiyong]

Sorry, did check email these days....

If you prefer creating components without `defcomp`, you can write `create-comp` directly. It's too verbose though. https://github.com/Respo/respo/wiki/defcomp

I don't intend to add Hiccup-like DSL to Respo. We alreay got Reagent and Rum for that. Respo is not designed to be that simple.

On Wed, Jun 14, 2017 at 7:46 PM Dustin Getz <dusti...@gmail.com> wrote:

Respo UI code is all functions but many of the functions are wrapped in defcomp at the place of definition. Is it possible to move the defcomp up to the root of the UI, so UI code is just functions and no dependency on the macro?

--

[jiyinyiyong]

That's really jumping. I can hardly follow that. Maybe we can talk about it here http://clojureverse.org/

--