Would you consider the server holding the schema?

sure, ideally it shouldn't matter right

I only ask as does electric make sense if no server exists?

You can use it client side only, in theory

this feels very tractable in electric, my standard for how “difficult” a project is has changed

starter apps are all getting paved fwiw

nice, how so?

we streamlined a lot of the little annoying complexities with the build/ops and some other stuff, i forget

it unfortunately got paused before completion as i am oversubscribed right now but willget back to it after i do my taxes

got it. happy to review or pitch in on the starter experience, feels like there’s a great opportunity for the long tail of programmers that might not fully grok deps.edn for example

will fix, is it breaking something?

well you can't use it because the e alias doesn't exist

it works if the caller ns binds that alias which of course it does, unless you have bound it to something else

I don't understand, it's the only thing in that file that uses e/ , and it was broken for me in my ui file with the usual e alias until I edited that electric source file

ok i will log a ticket, if you want the contributor badge send commit (and we will get to it faster too)

m/observe is the default way i think, in the case of electric-dom there is some nuance - mentioning this because i’m not sure what you’re trying to do

can you instead (dom/element :my-node-type ...)?

i want to render to pixi instead of dom, so trying to learn the details a little better. The event handling bits look hard, I don't understand yet why dom event stuff can't be in the dom namespace

https://github.com/hyperfiddle/electric/blob/master/src/hyperfiddle/electric.cljc#L183

tell us more about what pixi is and what you are trying to do?

pixi is a rendering library, mostly for games, like sdl or flash. it should be straightforward to port electric-dom's rendering model to any other retained mode system. I think this should trivialize making things like .io games

i saw that comment, but I don't know what it implies in general. I'm looking for a generic pattern of "m/observe this listener, and convert fn callback to e/fn"

electric ships an efficient clock on every platform and in the browser implementing that clock correctly depends on the visibility state which is a dom event

you can do the naive thing for events with m/observe, it’s the e/fn callback pattern that is problematic, we believe it’s an anti pattern now and it will be deprecated with electric UI5 which is callback free FRP based design

this pattern is in electric-dom, not electric-ui right? does ui5 replace dom

is the new design generalizable outside of dom events?

yes the new design should generalize, however it is currently blocked on differential electric

we can give you some old patterns we used to get by if you want, or perhaps you can copy/paste any electric- dom implementations

UI4 and dom2 are we believe correct and bug free if you understand how to call them correctly , but definitely not idiomatic long run

i'll wait on the proper way to do it, I've been looking at electric-dom just to try to understand what's going on and I don't get it 🙂

“hook” is a mechanism to track order in the DAG so that in an e/for-by if elements move around in the collection the underlying dom elements are gracefully swapped and not rebuilt. this is a central functionality in the differential electric rewrite, all this hook stuff is getting paved