Using Tyxml with React is straightforward and makes your pages reactive
almost for free.

If your page contains :
p [ text (string_of int i) ]
you juste replace this by
p [ R.text (React.S.map string_of int i) ]

and it is automatically updated when the value of i changes ...

And with Eliom you can even created these reactive pages from server side
...

Vincent


Le ven. 2 déc. 2016 à 14:42, Alain Frisch <alain.frisch@lexifi.com> a
écrit :

> Hi Vincent,
>
> First, let me insist that I have zero experience with functional
> reactive interface, Tyxml or React.  So I'm not in a very good position
> to comment on them!
>
> My *intuition* is that the tradeoff would be a bit similar to the one
> with Jane Street's Incremental.  Both FRP and SAC require to introduce
> extra concepts (signals, events, variables, observers; specific maps and
> binds) which add some weight compared to a simple one-directional "view"
> mapping from state to vdom.  What you gain with those approaches is a
> more fine-grained notion of update, which can be necessary in some cases.
>
> Interestingly, Elm moved away from FRP :
> http://elm-lang.org/blog/farewell-to-frp .  This is not just a shift of
> terminology, and it corresponds to the removal of the "Address" argument
> on the view function in favor of a parametrized vdom type:
>
>
>
> https://github.com/elm-lang/elm-platform/blob/master/upgrade-docs/0.17.md#no-more-signaladdress
>
> (In a sense, the "Address" argument is rather similar to the "inject"
> function which we discussed with Yaron.)
>
>
> About Tyxml itself: I think that it addresses a rather different set of
> issues (ensuring that the DOM is "statically correct" w.r.t. definition
> of HTML5/SVG).  We haven't identified those issues as being relevant for
> us, i.e. we have never hit a bug related to breaking such validity
> constraints, and the lack of static typing does not seem to make
> refactoring UI code more difficult or fragile; so it's not clear to us
> that adding more static typing here would help.  If we tried to combine
> it with our vdom approach, it would probably add some noise, since the
> vdom type would receive extra type parameters, which would be visible in
> the interface of all components exposing "view" functions.
>
>
> Alain
>
>
> On 02/12/2016 13:51, Vincent Balat wrote:
> > Hi Alain,
> >
> > How would you compare the virtual DOM with a functional reactive
> > interface, as you can do with Tyxml and React?
> >
> > -- Vincent
> >
> > Le mer. 30 nov. 2016 à 17:53, Alain Frisch <alain.frisch@lexifi.com
> > <mailto:alain.frisch@lexifi.com>> a écrit :
> >
> >     Dear all,
> >
> >     You might be interested in the ocaml-vdom project which has been
> used by
> >     LexiFi for some time and open-sourced recently.  It contains two
> >     components which we use to create our browser-side UIs with
> js_of_ocaml
> >     and which might be useful to the community:
> >
> >         - Bindings to the DOM and other browser APIs, implemented with
> >     gen_js_api.  (Partial bindings, expanded on demand.)
> >
> >         - An implementation of a "virtual DOM" and the "Elm
> architecture",
> >     i.e. a programming model where the UI is specified by a state type, a
> >     view function (producing a functional version of the DOM), and an
> update
> >     function that modifies the state based on messages (generated by UI
> >     events or external interactions).
> >
> >
> >     Project page:
> >
> >           https://github.com/LexiFi/ocaml-vdom
> >
> >
> >     -- Alain
> >
>