[Ur] Ur/Web first impressions

[Joachim Breitner]

Hi,

Am Donnerstag, den 18.03.2021, 19:36 -0400 schrieb Adam Chlipala:
> On 3/18/21 2:20 PM, Joachim Breitner wrote:
> > > > Obviously, I need to connect the above function to a source/signal with
> > > > the game state. I found that this works, although I wonder if this is
> > > > an idiomatic way to do so:
> > > > 
> > > >            <canvas id={canvas_id} align="center" width=500 height=400/>
> > > >            <dyn signal={
> > > >              ui <- signal ui_state;
> > > >              return <xml><active code={
> > > >                drawDisplayState canvas_id (displayState ui);
> > > >                return <xml></xml>
> > > >              }/></xml>
> > >   The idiomatic way would be to use the features of the FFI for adding
> > > change listeners on signals.  You may have been thrown off by the
> > > fact that the library you took as inspiration does no such thing!
> > > You'll find JavaScript function "listen" documented briefly on page
> > > 59 of the currently posted reference manual.
> > Yes, I remembered that mention, but given that both the source and the
> > code I want to invoke upon changes already lives in “Ur world” it felt
> > wrong to reach for the FFI. And it was expressible with just non-FFI-
> > features, as shown above… I guess either way is just a way to deal with
> > the fact that I am doing something uncommon (running possibly effectful
> > code upon changes to the signal).
> I should have been more specific in my suggestion.  Instead of exposing 
> a mutable datatype of canvases, I would prefer a pure datatype of 
> functional drawing descriptions.  Then you can give your canvas a type 
> like `signal picture_description -> xbody`.  I don't see a place where 
> we'd want an operation to listen for changes to trigger mutation.


Absolutely! Such a higher-level pure API is desirable. I have been
wondering about a “canvas_drawing” monad where the only side effect is
drawing to the canvas (so it’s pure, assuming the canvas is cleared). 

There is some trickiness. Maybe a single canvas has multiple areas that
should independently react to different signals, so you either have to
be pragmatic and expect users to clear and redraw only the the relevant
parts in the various “signal (canvas_drawing unit)” handlers. Or just
don't support that, and only support “always redraw everything” flows.

So I see the point of the argument that “whenever you feel you need a
`listen` function in Ur/Web, you are probably in the process of
providing a higher-level abstraction on top of it, and so using the FFI
internal isn’t too bad, so need to put it into Basis”.

Cheers,
Joachim

-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/