[Ur] Ur/Web first impressions

[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.
>> However, I also think of the type `source xbody` as a bad code
>> smell.  It is usually better to put your fundamental data model in
>> sources and then derive HTML from them using <dyn> tags.
> That’s what I ended up doing in the end, and it’s probably cleaner.
> (Although a part of me, when it sees a data type T that is only
> deconstructed by a single function T -> A, wonders why not create
> values of type A directly. At least in a pure language.)
The payoff from introducing an explicit data model is that you might 
find later that parts of the data you used previously should also 
influence other parts of the page, and you don't need to go back and 
change anything else -- you avoid "callback hell" of finding all the 
places a source was changed and adding new logic to modify some other 
part of the page.