This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
Looking into statecharts as well
> There is a macro version of the script element called sfn that can be used as a shorthand for script elements:
The macro i see seems to be called script-fn (https://github.com/fulcrologic/statecharts/blob/681b3d7383cfd0ae6332bed5c3d974b73271b365/src/main/com/fulcrologic/statecharts/elements.cljc#L248) -- is that correct?
If so, happy to submit a PR to either update the guide, or rename script-fn -> sfn
Yeah, doc fix. It’s in released code so cannot change the name of the macro…but could create an additional macro called sfn. I think perhaps I had intended to rename it but didn’t?
So, best fix is probably just ape the exising macro into one called sfn (keeping the old one) so that the docs are correct, but existing code doesn’t break
sounds good, will do later today!
PR to fix fop/assoc-alias in statecharts
https://github.com/fulcrologic/statecharts/pull/3/files
I have a suggestion for RAD. In the form there is a "TODO: Decide when to properly set the field to marked". I think this can be determined using a form option. You could call it something like mark-complete-events and it would be checked in the blur event and the attribute-changed event. It would be a map of set of event names to mark complete on. Here's an example with blur:
(defn mark-field-complete?
[form-class qualified-key event]
(let [mark-complete-events (some-> form-class
(comp/component-options ::mark-complete-events qualified-key))]
;; Regression in :event/blur that marks complete without :mark-complete-events set. Could be
;; changed to only check nil? in :event/attribute-changed
(or (nil? mark-complete-events) (contains? (set mark-complete-events) event))))
(defn blur
[{::uism/keys [event-data] :as env}]
(let [{:keys [form-ident] ::attr/keys [qualified-key]} event-data
;; Get the master form because input-blur! does not pass in the :form-key
form-class (uism/actor-class env :actor/form)
mark-complete? (mark-field-complete? form-class qualified-key :blur)]
(cond-> env
mark-complete? (uism/apply-action fs/mark-complete* form-ident qualified-key))))(defsc-form ThreadForm [_this _props]
{fo/attributes [thread/title thread/body]
fo/id thread/id
fo/route-prefix "thread"
fo/mark-complete-events {:thread/title #{:blur}
:thread/body #{:blur :change}}})Yeah, that sounds reasonable. The other possibility is to add an event handler that is global and handles a mark complete event, and then make it more of a UI control detail (the control can indicate change, blur, or complete). I hadn’t really decided what was ideal, and what is there was already working well enough for me. Your suggesting is nice in that the ui control does not have to really make a determination, and it allows for a default bw compatible behavior.
Yeah I personally would prefer it not to be based on the UI control. When I just have one field, regardless of what type of field that is, then I want it to be mark complete on change. If there's multiple fields, then sometimes waiting until blur is better
I think it should support a function, to make it dynamic. Right now there is just a macro to make a form, but there’s nothing preventing someone from making dynamic forms on the fly. So, using the option-utils/?! (optionally run) function on the option in those functions would be good…not sure what arguments should come in, but it could return the map from property key -> event set
then to be similar to the other standard options, there’d be an attribute-level option, and a form level option, so you could put commonly repeated options on the attribute, and override them at the form level
I guess it could be the same key, and just adapt based on where it is: It’s a set or (fn [FormClass] set?) when it’s on an attribute, and it’s a map or (fn [FormClass] {k set}) on a form?