Solved. I had,

(e/defn SomeView []
  (dom/div ...))

;; lower down:
(e/server (SomeView.)

(e/defn SomeView []
  (e/client
    (dom/div ...)))

I hope incremental will be able to show which e/fn is the culprit :)

search m/sleep it's been discussed

(the major gap that I see being that the state of electric's nodes obviously don't persist between process restarts)

otherwise, electric is more or less exactly what I'd want out of a build system

not familiar with bazel but yes agree, "effect system" structure unifies a huge amount of infrastructure that today is disjoint

I maintain a list:

• hot take: the following technologies unify under the umbrella concept of "functional effect system" ◦ Kubernetes ◦ Erlang process supervision ◦ Microsoft Orleans ◦ Akka ◦ Rx ◦ Zio ◦ Cloud Haskell ◦ Clojure's Missionary ◦ Electric Clojure ◦ Unix, Windows (process/program/task manager) ◦ Java threads, OS threads ◦ Frontend rendering with signals

• value prop — functional effect systems ◦ cancellation ◦ concurrency and backpressure combinators ◦ composability / referential transparency – coordinate large scale effect fabrics ◦ glitch-free event propagation ◦ correct error handling by default (process supervision) ◦ resource lifecycle (RAII) – strong resource cleanup guarantees

• List of relevant topics: ◦ Process supervision (trees) ◦ Observable sharing (DAGs) ◦ Graceful termination ◦ Self-healing software ◦ Resilience ◦ Actors ◦ Signals and event streams / FRP ◦ functional effects ◦ concurrency and backpressure

> Bit of a shower thought – electric's semantics are more or less exactly what you want out of a polyglot build tool like bazel > Or the semantics for a "thing to manage your system" like integrant or component. Feels like integrant solves the narrow, parochial version, whereas electric solves the general version. On that sidenote, JVM only Electric could make sense - for cases where one wants the reactivity, but don't want reactive web clients.

> JVM only Electric could make sense CLJS only could be useful as well for that matter. Essential allowing Electric reactivity without requiring the websocket connection. (And then disallowing e/server & e/client when there is no connection)

JVM and JS only i think already works (just don't use e/client e/server) – the e/run unit test entrypoint mocks out the network. However the runtime overhead for network management is still present (may not matter)

Indeed electric dynamic scope is roughly competitive with Component and other DI frameworks

We don't advertise it because we have not done like a requirements analysis to figure out exactly what we have and don't have for a general purpose DI use case like that ... we're super focused on web UI. Using Electric for a different use case likely will have rough edges or some mismatches with how Clojure programmers might be accustomed to structuring your systems, we don't know yet

Right—to get something as nice as Integrant for local development with Electric definitely requires some thinking and some work.