Re: [Caml-list] Announce: ocaml-vdom (pre-release)

[Alain Frisch <alain.frisch@lexifi.com>]

Hi Yaron,

On 30/11/2016 20:22, Yaron Minsky wrote:
> I'm curious if you have any story for making the recomputation of the
> virtual-dom itself more efficient.
 > ...
> That said, for small UIs, this kind of incrementality is less
> important, so whether this is worth doing may depend on your
> applications.

Our story w.r.t. updating the vdom itself is the same as Elm, I believe:

1. In the vast majority of cases, the mapping from the "state" to the 
vdom is very quick and it is ok to recompute the full vdom on every 
state change.

An argument often made in the vdom space is that a UI usable by 
human-beings cannot possibly have a very big DOM (moreover, even recent 
browsers such as the latest Edge or Firefox struggle with tables 
starting at a few thousands rows), and that computing the full vdom 
"cannot be that costly".  I don't want to enter such discussion here, 
but in our own use cases, we indeed try to avoid "overly big UIs" and we 
don't have strong performance requirements such as continuous streams of 
updates pushed by the server; if it takes 10ms to react on a user UI 
event, it is perfectly fine for our case.  My intuition is that most 
applications would be a similar situation, but I appreciate that you 
have very different kinds of UIs and performance constraints that 
require a more incremental approach.

2. The library provides:

val memo: ?key:string -> ('a -> 'msg vdom) -> 'a -> 'msg vdom
(** Apply the function to generate a VDOM tree only if the function
     or its argument have changed (physically) from the previous
     synchronization. *)

(similar to Elm's Lazy: 
http://package.elm-lang.org/packages/elm-lang/html/2.0.0/Html-Lazy )

This is typically used when embedding the view of a "sub-component" 
derived from only part of the our current state.  If we can ensure this 
sub-part remains the same, the previous vdom (at the same "site") is 
reused, which skips both the vdom generation and the vdom diffing. 
Typically, the generation function would be a toplevel declaration (so 
it will always be the same, physically) and we arrange to avoid touching 
the part of the global state on which it depends.

Of course, it is also possible to use any other mechanism (such a 
memoization table) to reuse previously computed vdoms.


> Another thought: you might want to consider the design we used for our
> wrapper on Matt Esch's virtual-dom library. In particular, in our
> design we don't need a type-parameter for vdom nodes determining the
> type of a message, and we don't need the corresponding map
> functions. Instead, we use open types and a registration and dispatch
> mechanism for values thus injected.


Thanks for the hint.

Do you have pointers to code examples using the "inject" function?  It 
seems to me that you will need to apply to it produce any "message" in 
the view function.

In our library, you can write directly:

      input "+" ~a:[value "+"; type_button; onclick `Plus]


With the "inject" approach, do you need to write it like:

      input "+" ~a:[value "+"; type_button; onclick (inject `Plus)]

?


If so, this does not seem strictly lighter than using the "map" function 
occasionally.  Moreover this seems to open the door to possible problems 
if a vdom fragment producing some kinds of messages is injected in a 
"host application" that cannot process these messages.  It also means 
that one needs to take the identity of the "inject" function itself into 
account in order to memoize vdom-generation functions.

Basically, we need "map" on "component boundaries", and even not always, 
since components can take ad hoc injection functions to wrap their 
messages into their "host" own message type (as the SelectionList 
example in 
https://github.com/LexiFi/ocaml-vdom/blob/master/examples/vdom_ui.mli ).


The library does use extensible types (with a registration/dispatch 
mechanism) in two other places, though:

   - "Commands" (encapsulation of side-effectul operations).  The set of 
"command constructors" is small and has a global nature (e.g. "AJAX 
query", "timer", etc), while the type of "messages" is specific to each 
application and component.

   - "Custom nodes" in the VDOM which allow plugging "native" components 
(again, the set of such possible components is more "fixed" than messages).


Alain