Is it substantially different from https://tonsky.me/blog/humble-signals/?

That looks super interesting. I’ll read it tomorrow. On first blush, no electric isn’t super different. It’s an incremental computation signal graph. However, electric is based on the missionary library, which handles both continuous time and discrete time events. The main difference between those is the system is ok with dropping continuous time signals for performance reasons. Anyway, electric is a clojure-like dsl that compiles to a missionary graph. Probably interesting to review at least, if not actually use.

This is likely the easiest entry point: https://youtu.be/xtTCdT6e9-0?feature=shared The video is solely about missionary and how it handles signal graphs over time.

One other thing I just thought of - it prevents visual glitches. If you have A and B (which depends on A), the UI is prevented from being in a state showing AB*, and waits until A*B* is shown.

;; humbleUI
(def *area (s/signal (* @*width @*height)))

;; missionary
(def *area (m/signal (m/cp (* (m/?< *width) (m/?< *height)))))

@U5P29DSUS How do signals help with vdom?

@U053XQP4S how do you know that “there are no active subscriptions”? Is there an explicit “unsubscribe” method?

Re. VDOM: Here's an electric example using the built in js/dom library for usage reference. https://electric.hyperfiddle.net/user.tutorial-7guis-2-temperature!TemperatureConverter Nothing too exotic, it looks kinda like react. Here's the dom library: https://github.com/hyperfiddle/electric/blob/master/src/hyperfiddle/electric_dom2.cljc#L52 I've selected and commented a couple functions:

#?(:cljs (defn dom-listener [node typ f opts]
           (.addEventListener node typ f (clj->js opts))
           #(.removeEventListener node typ f))) ;; How to setup and teardown an event listener on js/dom

#?(:cljs (defn listen> ; Listen returns an event stream. 
           ([node event-type opts]
            ;; I'm not fully sure what relieve is. 
            (m/relieve {}
              ;; observe creates a new signal based on a subject. it expects a function (fn [new-value-supplied-f])
              ;; The function can also return a no arg fn for teardown (see dom-listener) 
              ;;   when the observe is cleaned up.
              ;; It's expected that `(new-value-supplied-f new-changed-value)` is called when the value changes.
              (m/observe #(dom-listener node event-type % opts)))))) 
(defmacro on
  "Run the given electric function on event.
  (on \"click\" (e/fn [event] ...))"
  ;; 
  ([typ F] `(let [[state# v#] ;; F is a signal processor. For each new value spawned by `listen>`, send it to F,
                              ;; BUT if that signal hasn't finished propagating and a new value comes along, discard
                              ;; the older process and continue only with the new one. 
                              ;; @leonoel will have to check me on this understanding
                  (e/for-event-pending-switch [e# (listen> node ~typ)] 
                    (new ~F e#))]

    ;; the real impl has more code handling `::pending` states but those aren't required to understand this
    )))

(defmacro element
  {:style/indent 1}
  [t & body]
  `(with (new-node node ~(name t))
     ; hack: speed up streamy unmount by removing from layout first
     ; it also feels faster visually
     (e/on-unmount (partial hide node)) ; hack
     ~@body))

(defmacro button {:style/indent 0} [& body] `(element :button ~@body))

;; This function creates a stream depending on the atom !hover-enabled?. When that value changes, the when branch 
;; is hit. If hover-enabled=false, then the consumer of the `listen>` stream is killed. Since no consumers are left,
;; the whole stream is closed and the consumer fn is un-mounted from the js/dom
(e/defn EnableOnHover []
  (let [!hover-enabled? (atom false) hover-enabled? (watch !hover-enabled?)]
    (button
      (when hover-enabled?
        (on "hover" (e/fn [_] (println "hovered!")))
      (on "click" (e/fn [_] (swap! !hover-enabled not))
      (dom/text (str "Hover enabled? " hover-enabled?)))

I'm super interested now after reading your article... I may try my hand at implementing your incremental-app example in electric

> Is there an explicit “unsubscribe” method? No. sub/unsub are not exposed to the user, they are managed by the operators. Each operator defines the lifecycle of its upstream subscriptions, in the case of *area it is the same as the parent but the logic can be more complex (e.g. with conditionals - when the predicate switches, signals in the previous branch are unsub and signals in the current branch are sub). > how do you know that “there are no active subscriptions”? Each signal has access to its active downstream subscriptions, so it's basically a refcount.

@U050UBKAA also feel free to correct me about your implementation, I've not read it just inferred it from your blog post