afaict, permissions would work like in any web software, your server side calls should only access what the current user is allowed to do

I don’t see why you couldn’t build a form in electric, but… even every reader will need a websocket connection and therefore resources from the server. I would wager that if a forum is publicly browsable, it is much easier to cache unauthenticated pages with a traditional full page server side rendering solution.

I don’t know the internals that well, but it seems it would be difficult to cache the WS messaging in any meaningful way

not a good fit yet, need SSR and “resumable” rendering, all of which are naturally done from signals based rendering approaches as proven by Solid.js which is dominating SSR benchmarks right now

however even though it can be done, “website” type apps is not our current focus today; Electric today is for ultra dynamic stateful apps like google docs or webflow or IDE

like we want to rebuild datascript in electric clojure so we can make the query engine network transparent, slice the indexes so they are partially client side so that “last mile” filtering happens on the client - offline first datascript! that’s what the kind of thing electric clojure is intended to make possible

on the other hand, if you tried to build a forum with electric today, the client/server boundary can be refactored and moved around at will, so you could choose to preload the page in one message and then not load anything else until you navigate

so in theory you could probably make it work, even release the websocket when not needed, or use cloud flare durable objects (edge network for websockets with durable state) - lots of possible ways to scale this

Interesting, is there a way to release and restart the ws?

Would you serialize some representation of the state to ”resume” from?

I've done a bit of hacking on DS, would be happy to lend a hand with that

No good way to restart the WS today (it reboots the page if you do, both client and server). We already did a first POC of resyncing state on reconnect, but hit a design flaw in the wire protocol preventing us from doing it efficiently. Maybe next iteration? historically we do a major revision about every 3 months

Interesting about possibly rewriting Datascript in Electric. I'm sure other things (like Electric itself) are higher priority but I'm curious if this has been started? Offline first datascript sounds pretty cool. I've also come across Asami which could be interesting as it also runs in browser.

we did some early analysis work, it could be POCed in a couple days

Did you see the SQL hello world: https://gist.github.com/dustingetz/1960436eb4044f65ddfcfce3ee0641b7

I did see that I had separate question about that I tried to follow that and wrapped the snippet in a try catch and e/wrap the db calls but I got no output no error. So if I understood the example correctly, atom changes which triggers the watch so any code within the scope of that watch is rerun?

changing the atom causes the watch to update, which causes any expressions that depend on the watch to update (but not the whole scope, it is fine-grained updates based on a reactivity graph)

Did you e/watch the atom to get the valua?

um, yes i have that

good q

#(:clj (defonce !users (atom (list))))

(e/def users (e/server (reverse (e/watch !users))))

for examlpe, although want 2 generalize

fwiw, this works for me

(e/defn AtomTable [val]
  (e/client
   (dom/table
    (e/for [[k v] val]
      (dom/tr
       (dom/td (dom/text k))
       (dom/td (dom/text v)))))))

(e/defn Other []
  (let [atom-map (atom {:foo 42})
        atom-map-value (e/watch atom-map)]
    (AtomTable. atom-map-value)))

I can call AtomTable from another component and it renders ok

see https://github.com/hyperfiddle/electric/blob/master/src-docs/user/demo_3_system_properties.cljc

thanks i had an error in an unrelated swap! that was wrecking the component 😅

actually, not sure :thinking_face: can you define the atom outside the component as clj and still watch it? i'm getting 'n is not a function' :thinking_face:

yes

ok probably just a typo somewhere.

x)

make sure to watch the atom from the same place it is defined at

i define it on the server, then i want the ui component to ppulate a table of it... hmm

watch on the server, use the watched value on the client

e/for it on the server?

and then pass the resultant table to the client?

oh i see i can destructure on server x)

sure

Sure!

any ideas how could we improve the tutorials? what document do we need to write that would have gotten you what you need quicker?

no idea. the way i was doing it was wrong and the example was right x)

i don't mind the learning curve. it is factored into the cost of taking on a new framework always. in this case, it is very profitable because i only need to learn it once to be productive many times. i looked at a basic example and went as far as i could writing code myself.

but when it didn't work as expected, i had to turn to the examples again. i think a side-by-side page of the code and the demos would be lovely and probably helpful. a big game changer for me was creating the AtomTable component and being able to live introspect changing values on the page while working / recompiling. a peek into the "db" of the app. i think those sorts of things will help people grok faster.

do you have code for AtomTable that we should include in a tutorial? send me some scraps of what you have and i'll think about how to include it

ty for the feedback & ideas, keep it coming