This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-06-01
Channels
- # announcements (20)
- # babashka (3)
- # beginners (30)
- # calva (28)
- # cider (3)
- # circleci (4)
- # clerk (27)
- # clj-kondo (72)
- # cljdoc (15)
- # cljs-dev (1)
- # clojure (85)
- # clojure-europe (37)
- # clojure-nl (1)
- # clojure-norway (13)
- # clojure-spec (7)
- # clojurescript (19)
- # clr (1)
- # conjure (11)
- # datahike (2)
- # datomic (11)
- # emacs (26)
- # events (4)
- # hoplon (35)
- # hyperfiddle (41)
- # jobs (7)
- # lsp (10)
- # nrepl (3)
- # off-topic (57)
- # portal (47)
- # practicalli (1)
- # rdf (3)
- # reitit (21)
- # releases (1)
- # testing (6)
- # tools-build (16)
- # wasm (1)
- # xtdb (16)
Hi, I’m looking into the xtdb starter code. I wonder why we have to define a latest db like https://github.com/hyperfiddle/electric-xtdb-starter/blob/ffe3ed23cc51e7dd7a001263b52d52a6fd00738a/src/app/todo_list.cljc#L69, since the xtdb tutorial doesn’t do this.
it’s reactive, that function is subscribing to the stream of tx changes and using that to automatically refresh the db val
Any known issues with slow Internet causing Electric Websocket to drop on timeout and render a blank screen? Requires reload to recover:
2023-06-01T11:07:44Z app[3d8d1ddbe43e89] jnb [info]ERROR hyperfiddle.electric-jetty-adapter: Websocket handler failure
2023-06-01T11:07:44Z app[3d8d1ddbe43e89] jnb [info]clojure.lang.ExceptionInfo: Websocket pong timeout.
2023-06-01T11:07:44Z app[3d8d1ddbe43e89] jnb [info] at hyperfiddle.electric_jetty_adapter$make_heartbeat$cr7506_block_4__7516.invoke(electric_jetty_adapter.clj:22)
2023-06-01T11:07:44Z app[3d8d1ddbe43e89] jnb [info] at cloroutine.impl$coroutine$fn__5168.invoke(impl.cljc:60)
2023-06-01T11:07:44Z app[3d8d1ddbe43e89] jnb [info] at missionary.impl.Sequential.step(Sequential.java:88)
2023-06-01T11:07:44Z app[3d8d1ddbe43e89] jnb [info] at missionary.impl.Sequential$1.invoke(Sequential.java:112)
2023-06-01T11:07:44Z app[3d8d1ddbe43e89] jnb [info] at missionary.core$absolve$fn__5532$fn__5533.invoke(core.cljc:141)
2023-06-01T11:07:44Z app[3d8d1ddbe43e89] jnb [info] at missionary.impl.RaceJoin.terminated(RaceJoin.java:51)
2023-06-01T11:07:44Z app[3d8d1ddbe43e89] jnb [info] at missionary.impl.RaceJoin$1.invoke(RaceJoin.java:71)
2023-06-01T11:07:44Z app[3d8d1ddbe43e89] jnb [info] at missionary.impl.RaceJoin$2.invoke(RaceJoin.java:86)
2023-06-01T11:07:44Z app[3d8d1ddbe43e89] jnb [info] at missionary.impl.Sleep.trigger(Sleep.java:63)
2023-06-01T11:07:44Z app[3d8d1ddbe43e89] jnb [info] at missionary.impl.Sleep$Scheduler.run(Sleep.java:35)
Hmmk, blank screen issue might just be OOM.
Yeah this is the 60 second timeout, if a heartbeat is missed for 60 seconds the connection is dropped
I believe the starter app is configured to auto-reconnect
https://github.com/hyperfiddle/electric/blob/master/CHANGELOG.md has a screenshot of the auto-reconnect
Yes, the page will teardown (turn white) on disconnect (losing state), and then boot again on reconnect. In the future, it won't lose client state, rather it will preserve the state and gracefully reconnect as if nothing had happened – this feature is blocked on the big refactor that Leo has been working on
However making an interactive app with forms and such work gracefully despite intermittent connectivity is a tall order, essentially asking for offline-first software. This is something we're thinking a lot about for electric-ui5 which we've been designing, however I can't promise we will solve the problem of offline-first as that's not actually the problem we're trying to solve, we're actually working on optimistic updates which is closely related to offline first but not quite the same
Thx. Possible to throw an Exception like Pending
when Websocket is down so I can catch it and disable things on UI, but preserve read-only state? E.g. (try … (catch Offline ex …))
? I’m okay with Electric throwing an exception if it can’t run a Fn that happens on the server.
If offline-first worked with Electric it feels like it would be the best of all worlds. I know the focus is internal web apps, but offline first opens the doors to all kinds of things eventually like mobile apps. Im curious though, would this involve somehow getting XTDB (or some other DB) to work in the client as well as the back end, and sync between them? I'd love an offline-first capable datalog DB, and haven't found anything except for those below. Is a client-side XTDB part of what would be required for optimistic updates? https://www.instantdb.com/ (Datahike seems to have left the client side for now, and Datascript only seemed maybe made for this?)
I'm trying to better understand what does/doesn't result in efficient network-traffic/rendering but I'm not really comprehending the behaviour I see. The following code is adapted from your system-properties example:
#?(:cljs (def !search (atom "")))
(e/def search (e/client (e/watch !search)))
(e/defn ActiveSearch []
(e/client
(let [
;search (e/watch !search)
result (e/server (take 10 (when (seq search) (search-by search))))]
(dom/div
(ui/input search (e/fn [v] (reset! !search v))
(dom/props {:type "search" :placeholder "Search by"}))
(when (seq result)
(dom/ul
(e/for-by identity [item result]
(dom/li
(dom/text item)))))))))
Like this the code runs fine, but if I do the e/watch inside the let-binding (like is now commented-out) I get obvious flickering and the inline-style trick shows that the results are indeed rerendered on every change. What's the big difference between these scenario's?adding line numbers
on L9, result
is in client scope, so result
transfers at this point
the pattern you want is this:
(e/server
(e/for-by [item (take 10 (when (seq search) (search-by search)))]
(e/client (dom/text (pr-str item)))))
here, each individual item
is in server scope on L2 and transfers as an individual item on L3, resulting in streamy networkYeah thats actually the understanding I had, it's just not the code I would have written myself if I hadn't seen the demo. So I tried to verify that what I would write indeed doesn't work efficiently but got confused by the results I got. Looking at it again I think I now understand why it seemed to work efficiently to me. I concluded this because the added inline-style stayed on the item even after getting new results. But I guess e/for didn't update the item because the key didn't change but the whole result-set is still transfered over the network on every change. Is that right? That doesn't explain the other behaviour I reported though. If I uncomment line 8 I get obvious flickering and the inline-style goes away on every change, I don't have that if I use the global definition of line 3. Is that to be expected?
You observe a difference in behavior when swapping L3 for L8, one flickers the other doesn't?
That surprises me, i'll need to repro that
Can you send me your repo link that can repro the issue?
This is what I see :
oh by "flickering" you mean "it lost the style" ?
No I also see flickering, but that's a bit less concrete than the example I gave now
Ok I repped and confirm it's the when
, im not sure exactly what's happening, it seems like a very subtle race condition
Regardless the answer here is to fix the e/for usage to have efficient transfer, do you have that working now?
I think the when
is trashing the body when the test blinks Pending
the question is really, why isn't there a Pending when we use the global def vs the local def
I’m trying to look into the starter code from xtdb. I found a e/for-by function, which is (e/for-by :xt/id [{:keys [xt/id]} (e/offload #(todo-records db))] (TodoItem. id))
. I found it difficult to understand the syntax of the api.
1. What is the :xt/id means that next to the e/for-by?
2. In (TodoItem. id)
, where is the id comes from, is this the special name when you are using e/for-by?
this might help for the first question https://github.com/hyperfiddle/electric/blob/15fb0219ff0d4daf507bd513750c698502700d2a/scratch/dustin/y2023/pokemon.md?plain=1#L29
some explanation of for-by is here: https://electric.hyperfiddle.net/user.demo-system-properties!SystemProperties
if you have used React.js, :xb/id is used here in a way that is similar to "react key"
Thank you. But I wonder why it will be come`id` not xt/id
. For example, in https://github.com/hyperfiddle/electric/blob/15fb0219ff0d4daf507bd513750c698502700d2a/scratch/dustin/y2023/pokemon.md?plain=1#L29, it will be display_name
after using the :key
to destructuring.