I heard a rumour that it is not advisable to put the state of forms in the re-frame db, is it true?

@stathissideris I took a swing at it a while back and opted to build a framework for managing form state in Reagent instead. Some of the issues I ran into I’m sure are solvable but seemed to be more easily solvable using local state management. One issue had to due with controlled inputs and dispatching on-change events, and enforcing validation / applying masks. There was a timing issue that added a bit of a delay on the client while they were typing that was difficult to work around. I was working on something that would allow for input A’s value conditionally effect input B’s validation so I was managing all the form state and validations in re-frame. Was just poking around again to see what others were doing and found this https://medium.com/@kirill.ishanov/building-forms-with-re-frame-and-clojure-spec-6cf1df8a114d which looks interesting and looks like it adds a dedicated subscription to each field may have solved some of the issues I was seeing. Another issue that I ran into was clearing form state. Returning to a form that had state that was previously filled out but not submitted would pre fill. Easily solvable by writing a component that wraps the form and dispatches a clear event on unmount, but even easier to just let react clean it up for you on unmount. Also felt a little uneasy about storing PII (passwords, etc..) in re-frame since I do persist parts app db to local storage, and also send parts of my app db to an error reporting service.

thanks for the detailed answer, I’ve seen this article before and I remember disagreeing with some aspects (can’t remember what). I’ll have a re-read

Yeah just did a quick skim of the re-frame section

My rule of thumb is if any other component needs to see the state, put it in the app-db. So something like a tooltip that has a visible/hidden state, that’s 100% local so you can keep it out of the app-db. Something like a text field, maybe only the field cares what the current state is, but maybe other components will care too. Let’s say it’s a Confirm Password field. There’s probably a matching Enter Password field, and each one cares about the state of the other, because the two passwords have to match. Put that in app-db.

::set-field-value! how is this not an anti-pattern? (referring to the article)

You might also be interested in the talk I did at the last conj: https://www.youtube.com/watch?v=JCY_cHzklRs

@manutter51 that certainly looks relevant, I’ll watch it and may come back with more questions!

many thanks

Just made an interesting discovery: if you accidentally type a backtick in front of (re-frame/reg-event-db ...), it will silently fail to register your handler.

makes sense, the backtick will convert it into data

Yeah, it’s not “wrong,” it’s just probably not what you want. Especially if you hit the backtick key by accident, and didn’t know it.

@manutter51 the same would happen with any form, not just with (re-frame/reg-event-db ...)

Interesting, I guess it would.

And the moral of the story is “Be careful when you reach for the Escape key.”

:imap jk <Esc> 😄

(with humour, but it's a serious suggestion, inferring that you use Vim. Really handy, and let me take the dumb lightbar Macbooks in stride.)

^[ is also ESC

stay on the home row