Hi @Lu, what are your thoughts on storing the form state in the re-frame app-db? You could allow a reagent cursor to be passed in so that reset! and swap! still work - that might have minimal impact on the code.

Hi @U055DUUFS, I will give this a thought. Out of curiosity, why do you want to store the form values in the re-frame db before submission?

That's a good question. I'm not going to have a perfect answer but here's the core approach we use. I think there are two types of state to be considered.  Widget state - like the string a user is typing into an integer field.  Field values - like the integer value the widget produces when the user is finished typing. I’m fine with not seeing the transient state in app-db.  It’s been a peformance issue in the past. A fiddly bit is knowing when transient state becomes field values.  Easy cases are stateless controls like a checkboxes and an input field which provides a clear onblur event. We have complex forms where the current field values can change what is presented.  That can get messy. We store field values in app-db. Handlers and subs apply “form logic” before processing or providing data to views. Examples  • showing/hiding fields • setting error flags & showing error messages • changing options • setting or resetting related field values • enabling save button if validation passes We now lean towards a combination of :default-value and incrementing :key to use uncontrolled inputs which stay in sync app-db form field values (after logic is applied).

Does it work with no re-frame at all? I love reagent but dislike and dont use re-frame.

Yep, I think so.

@U1QQJJK89 Re-frame is used in a couple of places at the moment.. so it's not completely decoupled from that dependency

@U055DUUFS I see... I used Fork with similar requirements, and what I did was to dispatch re-frame events on blur to store the final input values. You can pretty much do all of the above with the lib, but it would definitely cost you a rewrite... Talking about validation, I assume you want it to run only on the coerced values, so you would not want to use the :validation handler I am providing that runs at each re-render on the local state values... I am not sure whether it makes sense for you to use Fork, as it seems you already have a pretty worked out customized form flow. The question I'd ask myself is whether what you have would look cleaner and more maintainable in Fork. If the answer is yes, I would mock out something and give it go; otherwise, I would just stick with whatever you have in place 🙂