I like Benjamin's solution. To me, it clearly leads to better code,
even independently of this issue. I always try to avoid querying SQL
row data that won't be used.
The problem has to do with embedding of server-side values in
client-side code. The type [client] should only appear in server-side
code, so it's proper for the compiler to signal an error when
[client]-containing variable [row] is mentioned in a GUI event handler.
The error message arises because this faulty embedding prevents the
compiler from translating code to JavaScript, and therefore the code to
get the mouse-event info remains in server-side code, which isn't
allowed, because only client code can call that function.
Clearly not a nice error message, but I don't plan to fix it, per se. I
have longer-term plans to reimplement Ur/Web or a similar system in a
nicer way that avoids the problem with static typing.
Post by Benjamin BarenblatI'll really appreciate if someone can help us. It shouldn't take more
than a few minutes - https://github.com/urweb/urweb/issues/94
This took a bit more than a few minutes, and I'm still not entirely sure
what's going on, but I eventually figured out how to fix your particular
problem. I ran the compiler with the `-explainEmbed` flag, which gives
more information about errors like this, and got
Can't embed
loc: peers.ur:20:20-21:3
e: UNBOUND_1.Peers.A
t: FFI(Basis.client)
peers.ur:20:20: (to 21:3) Server-side code uses client-side-only identifier "Basis.mouseEvent"
So I tried changing your `onclick` handler to avoid capturing
`row.Peers.A` - i.e., I changed your `SELECT` statement to
SELECT Peers.C FROM peers WHERE peers.A > {[me]} OR peers.A < {[me]}
and it compiled.
This is definitely a case of a bad error message, but there may be more
in play here. It sounds like the compiler is trying to evaluate the body
of the `onclick` handler on the server instead of on the client, which
seems wrong to me. This may also be related to Ur/Web's apparent
inability to handle client IDs on the client side [1]. In any case,
though, if anybody else has experienced issues like this, please speak
up.
As an unrelated aside, you can simplify your `SELECT` statement further
- Ur uses `<>` as the inequality operator, so you can say
SELECT Peers.C FROM peers WHERE peers.A <> {[me]}
with the same semantics.
Best,
Benjamin
[1] https://github.com/urweb/urweb/issues/96
_______________________________________________
Ur mailing list
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur