@flyboarder i have grown to dislike form builder DSLs
forms are very complex things once you move past the basics like text fields and checkboxes and the DSLs i've used in the past all ran into diminishing returns quite quickly
i've been trying different things, currently moving away from the idea of "a form" and more towards "interactive DOM elements" that update a passed in cell
the interaction with my db sits with the cell, not the form
e.g.
(defn item-attribute-cell
([conn item attribute] (item-attribute-cell conn item attribute nil))
([conn item attribute init-v]
(j/with-let [c (j/cell=
(attribute item)
(fn [n]
(assert (spec/valid? attribute n))
(when (not= n (attribute @item))
(j/dosync
(item.api/upsert-item!
conn
(merge @item {attribute n}))))))]
; upsert init-v if the attribute is not found
(when (and init-v (not (attribute @item)))
(reset! c init-v)))))
so... hanging things off spec and javelin lenses, basically
i could be way out of line here, but i feel the very idea of a monolithic form is tied to the idea of a form "action", which is tied to the idea of having a fat server doing all the work
@thedavidmeister interesting! My pattern comes from the idea that the state should not be tied to the form inputs, since those come from somewhere else
I think having a form state-machine should be something we can abstract from the elements
@flyboarder yeah, i agree that the "bigger" state shouldn't be tied to the form inputs
but being too strict about "zero state" elements restricts how dynamic/reusable/complex the elements can be
i think i'd like to hear more about what would go in the form state, that is beyond normal cell stuff
error handling is one thing to look at for sure
https://github.com/alexanderkiel/phrase is on my reading list because i want to tie things to spec more if i can, and someone mentioned that it could be used to convert machine predicates to human friendly warnings
Phrase is really interesting, there are many good ideas in there. Although I need to dive through the source more