[Ur] A (simple) project and some thoughts.

Sat Feb 21 10:11:03 EST 2015

After several partial projects, I finally made one simple enough that I
actually finished it before getting frustrated with Ur/web's quirks and
lack of documentation.  Ur/web is tremendous overkill for this project,
but it was a good learning experience.

All it does is look at the San Francisco and San Jose sports schedules,
and if there's a game at a time that will cause lots of people to ride
Caltrain, say so and change the color.  (If you're in the right
timezone, that is...)

http://willcaltrainsucktoday.com/
https://github.com/edanaher/willcaltrainsucktoday

(It's a bit silly; as the about page says, it's a takeoff of
http://isthereagiantsgametoday.com/ based on a silly tweet)

I do like Ur/web very much in theory, and now that I've done a decent
working example of simple SQL, RPC, and FRP, I hope I'll be able to use
it for beefier projects in the future.

Some thoughts/issues I had doing this (in no particular order):

1. Timezone handling is annoying if the client and server are in
different timezones.  Initially, everything was server-side, and it was
great.  Then I moved some of the computation client-side, and suddenly
it broke on my remote server, since I'm now on Eastern time, while this
assumes Pacific time.  I'm not sure of a clean way to fix this in
general, but since this really only makes sense if you're in California,
I didn't try that hard.

2. To set the color, I wanted to set a class on the <body> that
everything else could then work from.  Unfortunately, dynclass on body
didn't work.  I don't see any theoretical reasons why this wouldn't
work, but I certainly haven't investigated too deeply.

3. I had some issues with multiply-used signals giving bizarre errors;
see https://github.com/edanaher/willcaltrainsucktoday/tree/master/signal_test.
It seems like using a signal object multiple times leads to "TSignal
remains" errors.  The simple workaround is to think the creation of the
signal so that it's not reused, but it makes the code uglier, and I'm
mystified as to what the problem is (having not really thought about how
signals might be implemented).

4. Generated JS onclick handlers appear to always return false,
preventing the event from propagating.  I wanted to onclick the main
body to close the menu, but this prevented links from working because
the body ate the click first.  Changing it to onmousedown worked, but it
would be nice to be able to specify whether the event should propagate.

5. URL whitelisting is prefix only; I wanted to use
mailto:comments-[timestamp]@... for spam-blocking purposes.  But to
allow this link, I had to whitelist mailto:comments-*.  This isn't a
huge deal, but I'm wondering if there's any deep reason for this or if
it just handles the common URL case, so was never improved.

6. Maybe I've done too much Haskell, but I kept being lazy about let val
versus let fun (particularly when thunking the signals for (3) above).
The initial error message "This is an expression but not a pattern." is
extremely confusing, especially as it tends to point at an apparently
unrelated line.  The second error, "syntax error: inserting  REC", is
more helpful, but occasionally I managed to confuse the parser far
enough that I didn't even get that.

I hear there's work being done on a better infrastructure for compiling;
I hope clearer error messages are a part of that.

7. Generating a dynamic link (such as on/[year]/[month]/[day]) requires
generating the whole link tag dynamically instead of just substituting
the link in.  I found a reference online that this is because the
function name in the link needs to be used to generate the URL; this
makes sense, but seems to be an annoying limitation.