This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-10-28
Channels
- # aleph (4)
- # announcements (5)
- # babashka (28)
- # babashka-sci-dev (13)
- # beginners (63)
- # calva (76)
- # cider (113)
- # clara (7)
- # clj-kondo (42)
- # cljdoc (1)
- # clojure (170)
- # clojure-europe (20)
- # clojure-nl (17)
- # clojure-norway (3)
- # clojure-spec (12)
- # clojure-sweden (1)
- # clojure-uk (6)
- # clojurescript (55)
- # clojureverse-ops (1)
- # consulting (1)
- # core-async (9)
- # cursive (16)
- # data-science (1)
- # datascript (8)
- # datomic (27)
- # emacs (14)
- # events (1)
- # fulcro (10)
- # graphql (9)
- # gratitude (1)
- # jobs (6)
- # jobs-discuss (5)
- # leiningen (10)
- # lsp (35)
- # missionary (4)
- # nextjournal (9)
- # off-topic (46)
- # pathom (15)
- # pedestal (5)
- # polylith (37)
- # portal (15)
- # re-frame (22)
- # reagent (4)
- # reitit (5)
- # reveal (18)
- # shadow-cljs (20)
- # tools-deps (7)
- # xtdb (10)
With RAD I'm wanting to transact a local mutation when the user changes the value on a :select-one
picker. I was hoping there might be a hook for this (say ::picker-options/selectedAValue
) but there isn't. I suppose the 'RAD way' would be to have a ro/row-actions
- so a button on each row. But this would be confusing for the user as the button action would be a repeat of the intention.
Where do you have the picker? Is it a report action? Are we at all speaking about a report or about a form? I believe a report can only have a picker as either a report or row action?!
If you speak about a form then it fires form/input-changed!
which triggers :event/attribute-changed
- you can modify the UISM to trigger the additional mutation.
It does seem that a RAD form can have fo/triggers
that then has an :on-change
key. I'm looking at LineItemForm
in the RAD demo. Using an on-change trigger might be a bit more convenient than modifying the form state machine.
Good to see an example of modifying a state machine in the latest RAD demo (`master-detail-report-machine` - extending a forms machine will be the same as extending a reports state machine as done there). I'm sure I'll be needing to do that soon enough...
Ah, I was confused by your mention of report-options...
Yeah sorry I'll cross that out. Was irrelevant to the question and plain wrong anyway. Some kind of action button doesn't even make sense as a replacement for an onChange.
Triggers is probably the answer in this case. The other option is to install your own control "style" for that kind of control and allow it to take extra props/options. The final option is to just take control of the rendering of the form and do exactly what you want, while still having RAD support for form data.
That did occur to me as well. RAD starting to look like Oracle Forms - a good thing - a development environment that also had an 'ON-CHANGE TRIGGER'.
I'm not sure I like the comparison 😛 RAD isn't meant to be a bells-and-whistle kind of thing. It's meant to give you a fast way to stand something up for alpha/early stage, and escape to hand-written stuff easily and gradually as needed. So, while the feature set I'm supplying might satisfy a large chunk of "easy needs", I see the entire architecture as completely different.