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.
_______________________________________________
Ur mailing list
Ur@impredicative.com
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
