re-frame 2022-08-02 | Slack Archive

rgm17:08:20

I'm a fan of the idea that forms are "processes" instead of "transactions" (see https://www.bikeshed.fm/185), which tends to imply in my mind that even a simple one-field little modal form with no server communication can result in at least 3 re-frame event handlers: begin-form, commit-form, finish-form (eg. "cancel" ... also gets called by commit-form to clean up ephemeral form state or otherwise hide the modal). Do we have any helper libs or good examples to support this pattern? It's fairly straightforward to set up but feels pretty boilerplate and a bit tedious, which got me to wondering.

steveb8n22:08:41

I have found that clj-statemachine works really well for form state. The whole process can be emulated in a test and then integrated after

steveb8n22:08:19

That includes loading and flushing similar to your process concept

rgm22:08:14

yeah I tend to use clj-statecharts or metosin/tilakone (or often just a couple home-brewed fsm functions) elsewhere. I guess what I'm musing about is some way to programmatically derive event handlers from an FSM definition, so it's possible to see the forest for the trees.

steveb8n04:08:15

For that you can try a naming standard for events. Then the fsm can treat them as a validated output side effect

rgm15:08:57

Hm. Guess I'm expressing myself poorly. I appreciate the rigour of mapping re-frame events to eg. tilakone actions, but that seems to do nothing for the boilerplate-y-ness around the specific domain of a form with eg validations that fire only when dirty, maybe a couple of server-side checks, etc.

steveb8n04:08:53

Yeah, I think I from what you are imagining. I have a tool I hope to oss soon that will do what you want. If/when I do I'll try to remember to let you know here

rgm16:08:27

oh, that'd be outstanding ... happy to take a look and comment

2022-08-02

Channels