Fork me on GitHub
#hyperfiddle
<
2023-04-10
>
tobias13:04:10

Under what conditions does the websocket connection timeout? I tried giving each websocket session its own atom like this

;; Each websocket session gets its own atom. State not shared between browser tabs
(e/def !unshared-server-state #?(:clj (atom {})
                                 :cljs nil))
I noticed that if I leave my computer for 30 min and come back then the server atom gets reset to its initial (empty) value. Is this intended behaviour? Basically what I want is for each user to get their own server state (i.e. not multiplayer) but I don't want them to lose that state if they leave their computer and come back after lunch break. What's the best way to do that? This is for a very simple back office app with no database and no authentication. Right now as a workaround I'm storing all state on the client but I'd like to understand how I could do it with state on the server. Maybe I should be doing something like using a shared server atom and giving every user their own key inside it based on a random cookie I assign them?

1
Dustin Getz13:04:33

Let me split apart the questions: 1. how to do per-user state in electric? 2. how to make per-user state durable? 3. under what conditions is the connection lost?

Dustin Getz13:04:42

(1) see the atom in the https://electric-examples-app.fly.dev/user.demo-system-properties!SystemProperties L17. In Electric, all local state is tied to the lifecycle of the ws connection (and isolated to that connection) with the exception of global state

Dustin Getz13:04:45

(3) (a) connection is terminated gracefully when browser tab is closed; (b) connection is lost after 60 seconds without heartbeat (i.e. lost internet service, or went to another tab*), (c) connection is lost on server restart (e.g. deploy) *If you blur the tab, everything pauses (because we schedule all work with requestAnimationFrame) including consumption of the websocket (everything is backpressured). Connection is re-established when (a) the tab is focused again, (b) the auto-retry logic sucessfully reconnects. On reconnection, today the client reboots, losing local state. (We know how to implement resync on reconnect without client reboot, it's on the roadmap)

Dustin Getz13:04:12

(2) you'll need to write code for this, e.g. store it in redis, localstorage, cookie etc

tobias13:04:53

that makes sense, thanks for explaining

tobias13:04:01

system properties tutorial for other people reading this (link earlier went to local host for me) https://electric-examples-app.fly.dev/user.demo-system-properties!SystemProperties

👀 1
Dustin Getz13:04:42

thanks, fixed link

tobias13:04:25

Another question: My app has a slow operation (hitting some apis) that takes ~5 seconds when the user hits the "submit" button. What's the best way to show a spinner in the waiting period? I notice that ui/button pretty clever in that it automatically applies disabled and aria-busy="true" to the button during waiting, but is there also something I could do to conditionally display a dom element during that waiting period?

1
Dustin Getz13:04:50

the next tutorial shows how to do control load states, i'll try to publish it today

tobias13:04:20

Awesome, thanks! I also just noticed on-pending in another demo https://gist.github.com/dustingetz/2c1916766be8a61baa39f9f88feafc44 Is one way preferred over the other?

Dustin Getz13:04:44

yeah, on-pending is just a macro over the try/catch Pending pattern