It looks like there’s a mistake in the snippet. Sorry. binding binds in parallel (in both Electric and Clojure). Until we revise the snippet, you can try with:

(binding [!dirty (atom 0)]
  (binding [dirty (e/watch !dirty)]
    ...)

ok thanks!

No need, Electric has the mount/unmount lifecycle baked in.

(e/defn GetDbConn []
  (let [my-closable-conn (get-db)]
    (e/on-unmount #(.close my-closable-conn)) 
    my-closable-conn))

I get

ERROR hyperfiddle.electric: #error {
 :cause Wrong number of args (0) passed to: hyperfiddle.electric.impl.runtime/constant/fn--7241

...

in dynamically bound ( electric-starter-app.main/GetDbConn )

(binding [pg-conn (GetDbConn)] ... )

Electric functions (`e/defn` and e/fn) are called with new: (new GetDbConn) or the equivalent (GetDbConn.).

Ah thanks! but how does it work for e/fn then, eg in that snippet:

(CodeMirror. {:parent dom/node}
                            (e/fn [x]
                              (try (edn/read-string x)
                                   (e/server (reset! !sql-map x))     
                                   (catch #?(:clj Throwable :cljs :default) t
                                     nil))
                              x)
                            contrib.str/pprint-str
                            (e/server sql-map))

I don’t see anything wrong with this snippet. e/fn is called like e/defn:

(let [Identity (e/fn [x] x)]
  (new Identity 1))

I think what is wrong is that the code mirror expects a clojure/script write-fn, but then you can't have e/server in it?

a cljs fn and an electric fn are 2 distinct objects. If you are interoperating with a js library that expects a (cl)js fn you cannot pass it an electric fn. Are you trying to use our contrib codemirror namespace?

@U09FL65DK yes

I'm trying to update the value on the server when the content changes

My guess is that the try catch must be fully insulated on one side or the other

event just that fails:

(CodeMirror. {:parent dom/node}
                              (e/fn [x]
                                x)
                              identity
                              @!input)

#object[TypeError TypeError: n.call is not a function]

What is CodeMirror and what do you want to achieve

it's from the contribs: [contrib.electric-codemirror :as codemirror :refer [CodeMirror]]

I'm trying to update the value in the server when the content changes

Depends on what get-db does. If it acquires the connection from a pool or if it builds a fresh one.

yeah in my case it creates the connection pool:

(jdbc.connection/->pool
   HikariDataSource
   {:minimum-idle 10
    :maximum-pool-size  10
    :username "user"
    :password "password"
    :driverClassName "org.postgresql.Driver"
    :jdbcUrl "jdbc:"})

i've gotten vanilla lexical to work with a lot of hacking. maybe if i used react lexical the integration would have been simpler.

Off topic, but wondering if you've used ProseMirror and how you would compare it to Lexical @U066TMAKS? (Unrelated to Electric)

i haven't used prosemirror, but i think it's supposed to be the more mature option

what is the purpose for exposing ring-request in Main? (not too familiar with ring)

access to request headers and session variables

is there an example in fiddle?

if not, would be very nice

i figured out how to do it from the extended chat demo, which may or may not exist somewhere currently

Yes extended chat demo reads cookies. It is in the electric-tutorial fiddle.

ty @U2DART3HA!

(def !my-list (atom [1 2 3 4 5 6]))


(e/defn Entry [text]
  (e/client
   (e/on-unmount #(println "unmount" text))
   ;no single containing dom element
   (dom/div
    (dom/text text))
   (dom/div
    (dom/text "Foo"))))

(e/defn List []
  (e/server
   (let [my-list (e/watch !my-list)]
     (e/for-by identity [v my-list]
      (e/client
       (Entry. v))))))

(comment
  (reset! !my-list [1 2 4 5 6]); remove from the middle
  )

Ui before removal:

Ui after removal:

i couldn't repro that, this is what i get using your snippet:

i recently had some strange behavior around conditionals causing client/server mismatches, maybe check for that? https://clojurians.slack.com/archives/C7Q9GSHFV/p1706249048037089

Thanks for that hint. I carefully checked, that I do conditional requiring of namespaces that contain electric definitions. But I still get the strange behaviour. btw I am using electric version “v2-alpha-540-ga4699532”. Did you try to reproduce with the same?

it's the conditionals that cause the undefined behavior. e/defs need to be defined on both the server and the client (no conditionals) and there's currently no warning if one side is missing

i'm on the latest master

I have no e/defs in conditionals.

I try latest master later this day

I stil get the error with latest master. I only get corret behaviour, if I wrap each iteration step in another div like so

(dom/div (Entry. v))

how about try to repro on a clean clone of electric-starter-app or electric-fiddle? that would tell you if it's an issue with your specific app

I testet with the electric fiddle repo and extended the hello fiddle:

#?(:clj (def !my-list (atom [1 2 3 4 5 6])))

(e/defn Entry [text]
  (e/client
    (e/on-unmount #(println "unmount" text))
   ;no single containing dom element
    (dom/div
      (dom/text text))
    (dom/div
      (dom/text "Foo"))))

(e/defn List2 []
  (e/client
    (dom/div
      (e/server
        (let [my-list (e/watch !my-list)]
          (e/for-by identity [v my-list]
            (e/client
              (Entry. v))))))))

(comment
  (reset! !my-list [1 2  4  5 6]); remove from the middle
  )

(e/defn Hello []
  (e/client
    (List2.)
    (dom/h1 (dom/text "Hello world"))))

we will try to reproduce

I also suspect (like Wei) some sort of desync. The recent Electric incremental compilation changes made it easier to desync the frontend and backend using things like reader conditionals to cause the client and server to see different programs, we're still gathering info

It could also be a bug, the IC changeset was huge

yeah e/fn overhead is high in v2, and worse, each electric-dom2 container (div, tr, etc) has a hidden e/fn wrapping the children. Really new is what has the overhead and in electric-dom2, new is everywhere. This is a top dev priority, Electric v3 will be better due to resolving a bunch of technical debt (Spring release) and one consequence of Electric v3 is that all of the hidden e/fns inside dom containers are no longer needed, which might solve this issue outright

Yes there are optimizations you can do in the meantime – i'll get back to you, i'll make a short list

thanks! i can also wait for v3 if the optimizations are v2-specific. targeting a late spring release for this particular project

Can you copy paste the key parts of your code into a gist? DM me if you want to keep it private

sure, give me a few min 🙏

btw, does e/watch have significant overhead?

relative to, say, instantiating a e/defn

um, i'm not sure. Both involve new

do you have a lot of them?

maybe a dozen? not as many as i have inputs and defns. i'll treat them the same in terms of cost then

To follow up in public, step 1 is virtualized scroll, demo here: https://electric-datomic-viewer.fly.dev/(:app.datomic-browser!attribute,:abstract%52elease!name)

However, even in that demo, navigating between tabs is not instant, it's maybe 300ms to switch tabs (though not 1-2s). Some of this can be blamed on network delay but there is also clearly a waterfall load of sorts happening because the cells stagger in if you look closely

if the backend queries for the query/cells are slow, due to the waterfall this can really explode out, that's when you really need to optimize today. Heavy electric-dom2 usage also adds weight due to it's internal e/fns as mentioned above.

honestly we don't commit to anything, we're still triangulating what our requirements are and what user requirements are. electric-fiddle is intended to have "batteries included" and electric-starter-app is intended to document the cleanest possible entrypoint because electric-fiddle has extra complexity (due to so many apps co-existing each with its own classpath requirements)

the reality is that your app http middlewares (auth and such) are customized in 100% of real apps, so you have no choice but to understand the 100 line example http entrypoint

OK, I'll stick with electric-fiddle for now, and yes I've been putting off understanding the underlying parts properly but I'll have to figure it all out one day!

I'll add that electric-fiddle is far too fiddley today, it was shipped quickly and we're working on ways to improve it

That's true! I would probably get less conflicts on electric-starter-app. Thanks for the guidance as ever 🙂 Looking forward to the Differential talk