Clojurians Log v2

You can do parts of UI tree in cljfx, e.g.:

(require '[cljfx.api :as fx])

(defn- root-view [{:keys [state swap-state]}]
  {:fx/type :text-field
   :text (:my-app state)
   :on-text-changed #(swap-state assoc :my-app %)})

(let [cljfx-managed-text-field (fx/instance
                                 (fx/create-component
                                   {:fx/type fx/ext-state
                                    :initial-state {:my-app "state"}
                                    :desc {:fx/type root-view}}))]
  (fx/on-fx-thread
    (doto (javafx.stage.Stage.)
      (.setScene (javafx.scene.Scene. cljfx-managed-text-field))
      (.show))))

this is using ext-state, which sort of re-implements the renderer abstraction, but within the cljfx tree

you can do it with renderer too, but that’s going to be more involved, because you’ll need to invert the control a bit: you’ll need to pass a parent Node to the renderer, and then make a custom lifecycle that will put the root node into that parent

Thank you very much. It'll take a while for me to grasp as I don't know javafx 😅 . Just curious tho... if I put whole state in an atom then swap state, would cljfx rerender the treenodes that use that atom, or only the ones that depended on the part changed?

depends on what you mean by “rerender”. Cljfx will call all clojure view functions if their arguments change. The JavaFX nodes though will only be touched if their props that control them change

I’d say don’t worry about it too early, I only run into performance issues when I was trying to display too many JavaFX nodes on the screen (e.g. 20 pages of ui inputs) and the source of the performance issues was always JavaFX not being able to render that many nodes at the same time.

I see, it shouldn't be expensive then. I do, however, wonder about having lots of nodes: supposed I had 8 table views with 300 rows each, a section for each tableview updates several times a second, in addition to several graphs, timers, etc. is it ok to be swapping global state for each update , or is it possible to have local state management for each table for performance reasons

tables also should be generally more performant than other javafx nodes because they are virtualized, i.e. they show actual Nodes only for visible part of the table

I’d say making it easier for you to implement and reason about would be a more important consideration than potential performance issues when it comes to selecting a single vs multiple state atoms

Ohk, great to hear. I was thinking I'd have to implement some kinda infinite list if the table wasn't performant (5-6 updates per sec)

Yh, the global state is much more easier to reason about. only concern was in a complex tree, if it would still offer decent performance

Thanks a lot @vlaaad

my pleasure 🙂