This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-05-03
Channels
- # aleph (7)
- # announcements (6)
- # babashka (34)
- # beginners (5)
- # calva (1)
- # cider (3)
- # clerk (11)
- # clj-http (1)
- # clj-kondo (35)
- # clojars (6)
- # clojure (114)
- # clojure-australia (1)
- # clojure-brasil (2)
- # clojure-europe (73)
- # clojure-hamburg (3)
- # clojure-nl (1)
- # clojure-norway (27)
- # clojure-uk (4)
- # events (3)
- # graalvm (13)
- # gratitude (4)
- # helix (17)
- # hoplon (1)
- # hyperfiddle (65)
- # instaparse (4)
- # jobs-discuss (6)
- # lsp (2)
- # meander (2)
- # rdf (4)
- # re-frame (51)
- # reitit (28)
- # releases (1)
- # sci (20)
- # shadow-cljs (9)
- # tools-deps (4)
- # xtdb (44)
Hey, I figured out my websocket issue. Turns out you can proxypass
everything to whatever port the server is running and it should just work 😄
So that's good!
So now I just need to figure out how to retroactively add session support to the electric-starter-app
what specifically do you mean by “session state”, is there a framework you are referring to?
ah that used a cookie
then I think, a way to handle notifications & emailing stuff [via SparkPost] and a "nice to have" would be how much time users spend on pages and a "heatmap" for where the mouse is / what links they click. I wonder if it makes sense to work on an open-source version of that for the community
i think there are js saas analytics tools that do the heat map stuff
when i think of notifications i think mostly of mobile apps and slack notifications, are you making a mobile app?
yeah maybe can do heat maps with after party tool, just figured with a web socket already there, probably a lot that can be done
I believe so, have you encountered an issue? We transport with transit
I don’t think it does. I’ll have a repro case in a minute (or I will have my bug 🙂 )
(e/defn Main []
(e/client
(let [m (e/server (with-meta {:key "value"}
{:metadata true}))]
(println m (meta m)))))
the console shows {:key value} nil
i logged a ticket to look into it
what are you using this for btw?
My use case:
I have a server-side function that makes a rest call. If the rest call fails, I catch the exception on the server side and create an error map and return that error map to the client as a return value (not an exception). The error map has metadata on it that allows the client to know if the value it receives is an error or not.
As I write this, I realize I should try throwing an ex-info object from the server to the client.
Yeah, we will look into fixing it, a workaround would be to unpack the metadata in some way (into an ex-info or just a tuple)
btw, after a quick experiment, it doesn’t look like ex-info objects can be transmitted from server to client. I get error
java is not defined
in <unknown interop> {: :, :hyperfiddle.electric.debug/type :eval, :hyperfiddle.electric.debug/args (nil), :hyperfiddle.electric.debug/origin #uuid "2c01b195-c85a-4166-9d01-b26d44503c23"}
ok, please paste the snippet you used
My simple repro case fails differently:
(e/defn Main []
(e/client
(try
(e/server
(throw (ex-info "Does this survive?" {:some "data"})))
(catch js/Error ex
(println (ex-message ex))
(println (ex-data ex))))))
The first println shows the “Does this survive?” as expected. The second println is a bunch of electric internal data:
{:hyperfiddle.electric.debug/trace [{: :, :hyperfiddle.electric.debug/meta {:file app/plotly_interop.cljc}, :hyperfiddle.electric.debug/type :apply, :hyperfiddle.electric.debug/name hyperfiddle.electric.impl.runtime/fail, :hyperfiddle.electric.debug/args [<exception>], :hyperfiddle.electric.debug/origin #uuid "15aa5f8b-d49b-4b6a-b69d-9c5a3d9139e9", :hyperfiddle.electric.debug/serializable true} {: :, :hyperfiddle.electric.debug/meta {:file app/plotly_interop.cljc, :line 146, :column 7, :end-line 147, :end-column 63, :hyperfiddle.electric.debug/type :transfer, :hyperfiddle.electric.debug/name :hyperfiddle.electric/server}, :hyperfiddle.electric.debug/origin #uuid "15aa5f8b-d49b-4b6a-b69d-9c5a3d9139e9", :hyperfiddle.electric.debug/args [], :hyperfiddle.electric.debug/serializable true}], :hyperfiddle.electric/type :hyperfiddle.electric.debug/trace}
I’ll try to repro the java is not defined
case later today
this is probably just a bug, we may not have enough test cases for catching exceptions remotely
Here’s the java is not defined
repro case:
(e/defn Error [ex]
(dom/pre (prn-str ex)))
(e/defn Main []
(e/client
(try
(new (e/fn [] (throw (ex-info "Some error" {:key "value"}))))
(catch js/Error ex (new Error (ex-data ex)))))
new Error
is sus
oh nvm
Yeah, I was just looking at that
This code does not error:
e/defn Main []
(e/client
(try
(new (e/fn [] (throw (ex-info "Some error" {:key "value"}))))
(catch js/Error ex (new (e/fn [] (ex-data ex))))))
Does Error shadow anything from js? js/Error
Yes, I think so
Yeah I dunno if this is a bug or what, I will capture the ticket. I don't see signs of the original issue here
Original issue being metadata? That’s right. These are two separate issues
"it doesn’t look like ex-info objects can be transmitted from server to client. I get error"
That’s correct. The problem turns out to be two separate things: 1. https://clojurians.slack.com/archives/C7Q9GSHFV/p1683126839339759?thread_ts=1683125429.355749&cid=C7Q9GSHFV 2. https://clojurians.slack.com/archives/C7Q9GSHFV/p1683127360862209?thread_ts=1683125429.355749&cid=C7Q9GSHFV
I’m trying more javascript interop. This time with a library that depends on jquery. Specifically, I’m trying to translate this jsfiddle to electric http://jsfiddle.net/astrapi69/md1xztks/
I’m not sure if my problem is related to electric or not. There’s a good changce that I’m just doing the interop incorrectly
This is my attempt so far. It’s failing with Uncaught TypeError: $(...).gridster is not a function
try just
(-> (js/$ ".gridster ul")
(.gridster (clj->js {:widget_margins [10 10]
:widget_base_dimensions [140 140]})))
Now getting this
inst__30220__auto__.gridster is not a function
in ( .gridster (js/$ ".gridster ul") #js {:widget_base_dimensions #, :widget_margins #} )
in case default branch
in reactive (defn Main [] ...) in app/plotly_interop.cljc line 135
in (try ...)
if you comment the gridster interop out completely and open the web console can you call it from there with the js sample?
again with Uncaught TypeError: $(...).gridster is not a function
It’s as if something isn’t initializing correctly.
I don’t understand jquery well enough to know how it’s supposed to work
did you do what the readme said > Gridster is currently written as a jQuery plugin, so you need to include it in the head of the document. Download the latest release at http://jquery.com/.
ah, that’s probably the problem. Thanks for the pointer!
You gave me something to investigate - which is more than I had before!
In the https://github.com/hyperfiddle/electric-starter-app, how come ws messages are passed when I edit the text in the input field (for each key press)?
There's nothing that indicates to me that the F
function is called, except when Enter is pressed:
(dom/on "keydown" (e/fn [e]
(when (= "Enter" (.-key e))
(when-some [v (contrib.str/empty->nil (-> e .-target .-value))]
(new F v)
(set! (.-value dom/node) "")))))
(from https://github.com/hyperfiddle/electric-starter-app/blob/main/src/app/todo_list.cljc#L30)dom/on
calls new
on the supplied e/fn
for each keydown event. new
creates a new node in the graph. The graph is kept in sync between the client and the server
Ah, okay. I think I'm still not fully understanding why the server needs to know about this part of the graph on runtime
any node can request data from the remote peer. At that point you need to know who is requesting it. Having the same graph means you can reference it directly. As a theoretical optimization, if you can prove statically there will be no remote requests, one might be able to skip this step.
I endorse what Peter said, and will add that we haven't invested much in optimizations yet because we haven't seen any real world performance impact in our testing outside of 1-2 very specific cases that we're working to address. It's really only request/response waterfalls that damage performance as far as we are aware
Obviously as the compiler matures there is a path to making this hyper-optimized
We don't provide out of the box integrations for anything at this time, but happy to track requests