The design is that you roll up data in resolver on server, and invent a virtual attribute for that, but you can hand render if you want

Hm the one thing here is that if invent an attribute :project/tags ,which is aggregated tags, to put in the report, if someone edits a tag the virtual attribute won’t be refreshed automatically.

just a syntax nitpick/proposal: uism definitions seem unnecessarily noisy to me; would it make sense to be more concise/regular by inferring the top-level ::uism/events key, so it's just a map of events with a default override event to replace the current ::uism/handler functionality? e.g.

;; current syntax {::uism/events {:event/foo {::uism/handler foo}}} {::uism/handler foo} ;; more consise/regular syntax? {:event/foo {::uism/handler foo}} {::uism/all-events {::uism/handler foo}}

I noticed that having a {:query [(uism/asm-ident ::session/sm)]} will still not re-render when the uism changes state. I'm setting :shouldComponentUpdate (fn [] true) on the component anyways and that works, but from what I see, the book says that just adding the uism query should work

I have found a possible issue. When calling install-ui-controls! in RAD code it will store the UI plugins in app runtime-atom under the key :com.fulcrologic.rad/controls , it’s a map of stuff like com.fulcrologic.rad.report/style->layout . But in com.fulcrologic.rad.report the code will try to find installed formatters as such `

(some-> runtime-atom deref ::type->style->formatter)

So my client.cljs code has to look like this:

(rad-app/install-ui-controls! app sui/all-controls)
  (let [{::app/keys [runtime-atom]} app]
    (swap! runtime-atom assoc ::report/type->style->formatter
           report-formatters))