Fork me on GitHub
#hoplon
<
2017-11-20
>
flyboarder17:11:10

Has anyone created a properly abstract form component for hoplon yet?

flyboarder17:11:48

I’ll keeping throwing code up here while I figure this out….. but in my mind a form has a few different bits of state [fields data status messages] some convenience state could be made from status and messages like error, each field has it’s own state as well [data status messages]

alandipert17:11:51

flyboarder in the apps i've worked on, each had its own form abstraction

alandipert17:11:35

nothing really general has emerged from anywhere afaik, i think because styling can't really be extracted

flyboarder17:11:08

@alandipert what I am thinking is a bunch of state variables that can be used within the form elements

flyboarder17:11:39

fields for example could be passed to an element that builds the field based on it’s type (which is what I currently do)

flyboarder17:11:39

so all my fields are kept in a db, forms dont actually exist in the code

alandipert17:11:47

i see, that's cool. so you have a kind of form-builder-interpreter sounds lik

flyboarder17:11:14

yeah, except I always have to hard wire the state around the design, I’d like to move that state to a macro that builds it for me I think

flyboarder18:11:16

like err (j/cell= (when (= status :error) messages)) will always be a local formula

flyboarder18:11:36

the form fields could all store their state in data which keeps it local to the form but abstracts it from the field, so {:email email :pass pass} instead of 2 cells