This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-06-13
Channels
- # beginners (36)
- # boot (1)
- # cider (4)
- # cljsrn (2)
- # clojure (137)
- # clojure-brasil (3)
- # clojure-czech (3)
- # clojure-italy (17)
- # clojure-nl (8)
- # clojure-spec (7)
- # clojure-uk (153)
- # clojurescript (84)
- # data-science (2)
- # datascript (13)
- # datomic (30)
- # editors (64)
- # emacs (22)
- # events (6)
- # figwheel (26)
- # fulcro (7)
- # hoplon (5)
- # jobs (5)
- # jobs-discuss (57)
- # keechma (3)
- # leiningen (4)
- # luminus (1)
- # midje (2)
- # off-topic (26)
- # portkey (18)
- # re-frame (4)
- # reagent (10)
- # ring-swagger (3)
- # shadow-cljs (135)
- # spacemacs (5)
- # sql (14)
- # tools-deps (125)
@mynomoto the reason why it's nissit is that it's impossible to define a good default behavior. Various backends return errors in different ways, and it's often hard to get them in the per field format. Another question is the management of these errors - for instance when do you remove them? Is it enough to just change the value or do you need to submit again?
The easiest solutions which I used before is to have a server errors field in the form which you manually manage like any othe field and then remove before sending the data to server
@mihaelkonjevic Yeah, default behavior is hard. I would not worry about server response format we can always convert to what's needed. But I see your point on form interaction. Thanks for your suggestion, I'm placing server errrors outside the form so I don't have to remove those but can control how I display/remove them.