This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-02-27
Channels
- # announcements (8)
- # architecture (3)
- # aws (18)
- # beginners (96)
- # bristol-clojurians (3)
- # calva (15)
- # cider (7)
- # clj-kondo (8)
- # clojure (135)
- # clojure-denmark (1)
- # clojure-dev (14)
- # clojure-europe (37)
- # clojure-italy (9)
- # clojure-nl (14)
- # clojure-sanfrancisco (1)
- # clojure-spec (1)
- # clojure-uk (54)
- # clojurescript (27)
- # core-async (243)
- # cursive (28)
- # data-science (6)
- # datomic (33)
- # fulcro (25)
- # graalvm (24)
- # hoplon (2)
- # instaparse (12)
- # jackdaw (1)
- # java (21)
- # juxt (12)
- # meander (10)
- # nyc (4)
- # off-topic (6)
- # om (3)
- # pathom (17)
- # perun (1)
- # re-frame (29)
- # reitit (4)
- # rum (3)
- # shadow-cljs (119)
- # spacemacs (31)
- # xtdb (14)
Fork v1.2.5 - Form library for reagent & re-frame 🍴 https://github.com/luciodale/fork
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 🙂