we have not thought about module splitting yet, but after the current incremental compiler workstream lands this will be closer at least

Should be a relatively small proj - it's based on electric starter app. LMK if I need to trim it down to an MVP or if this is close enough to minimal to be understood

repo is private

public now

ty, what is mount-watcher ?

I needed something to wait for dom elements of an id to mount

or rather what are you using mutationobserver for

the viewers don't know anything about children, they just mount dom objects of ::view-options/id id and let children hang off that id by binding dom/with

very mutate-y heavy UI

if there's a better way for this I'm all ears though

at t=0 the table is rendered, and the dom elements for rendering A and B are attached. t=1 those two elements are seen and children for viewers are mounted

oh, without looking (on mobile) rebinding dom/node is undefined behavior in electric v2. this is supported in v3 which isn’t out. Because obviously it’s surprising for that to be UB and it’s a perfectly reasonable thing to want to do and quite powerful. In the meantime can this be expressed without rebinding dom/node?

Maybe. I'll give it a try. Sorry didn't know dom/with isn't supported 😬 - guess it makes sense that that's borked behavior

Might be able to get it into a tree of e/fn calls

yeah i now see you’re calling dom/with not rebinding dom/node, i need to go oook at the src when back at my desk later

got it to work basically in place with an atom of anonomized e/fn [] atoms. Pushed if you are interested.

i will try to look, good job figuring that out

i've had that exact same error rebinding node to js/document.body. workaround was to change render order for some reason

you shouldn't have multiple watches on the same atom I think? view-db/!id->view-fn

rebinding?

i would use a raw websocket for something like that today, use electric for the UI parts (you can have N websockets)

and not sure how i would do gapless playback, that would be a must

but maybe socket / channel logic is enough to do that in clj land

look at webtransport if you want to do something novel

does webtransport save me from having to make an iOS and android app? 😅 looks like HTTP3 supersocket basically main use case is mobile users so i ... wonder...

maybe, though I think you'd have to build a clojure webtransport stack first

someone will