This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (14)
- # announcements (3)
- # babashka (18)
- # beginners (32)
- # calva (1)
- # clj-kondo (65)
- # cljs-dev (5)
- # cljsrn (3)
- # clojure (22)
- # clojure-spec (13)
- # clojure-uk (53)
- # clojured (3)
- # clojuredesign-podcast (50)
- # clojurescript (8)
- # core-async (32)
- # cursive (15)
- # data-science (1)
- # datomic (17)
- # fulcro (48)
- # hyperfiddle (1)
- # off-topic (5)
- # shadow-cljs (2)
- # testing (2)
@tony.kay Great, thanks for the answers! About mark-missing: I understand the idea, yes, the question is why are nils considered as missing props and how safe it is for me to override this behavior.
Kinda scared to break some internals with this change, and it might be hard to catch related bugs.
Well, finally I’ve come to think it’s a bad idea to override a core function of 3 y.o., pretty much certainly would shoot myself in the foot sooner or later.
I need to distinguish between 3 states of the field: 1) no field => no validation (even if it is declared in form-fields) 2) nil valued field => validation should fail (i.e. marks pre-merge-initialized field as requiring input from the user; consider dropdown or number input, they both don’t have a default empty value, as text input has “”) 3) any other value => validation check
Well, validation may not fail on step 2, it should depend on your specs. This is more of a question of default empty value for fields which doesn’t have it naturally. Might go with some special keyword, like
i feel like you might be complecting the idea behind nil (of no value) and that of being required but currently empty
Well, for me it seems like I’m trying to decomplect those. Currently, Fulcro’s form-state spec validator checks fields which are really missing as having nil values. But specs describe the field properties, whether the field is required should be a parent spec concern (like
s/keys). When loading a form (with subforms) from the server, I might get both an empty form and a thoroughly filled-in one. Whenever I get an empty one, I’m adding fields (and subforms) in pre-merge, but I need to initialize those fields with something. Text input fields are easy, fields with natural / product default values are also easy, but there’re fields like floating point number input, which doesn’t have a default empty value, and generally in Clojure those are considered nils (“no value” === “default empty value” in this case). Thanks for diving in btw;)
Rather that they don’t have a default value, yes. And I’m trying to choose a good value to mark “no value yet” fields across the whole app. Basically, either I go with
nil for this, or with some custom keyword, which is processed as nil by UI inputs/dropdowns/etc
@fjolne.yngling it’s not central to any logic in Fulcro…Fulcro is simply trying to make a clear semantic for data merge. If your application logic considers
nil a “real” value that the server might return, then you can certainly rework it to be that way. It will not break any other logic in Fulcro, because there is no other logic.
we could easily add mark-missing to the app algorithms for pluggable stuff, and make data fetch and mutations allow an override that way
the only other place it is used is in
merge-component …that one would have to be a named parameter I think, since app isn’t passed in as an argument
however, do consider that you already have tri-state field support in form state, so dealing with nil should not be part of validation IMO
and once complete, should have a valid value….if nil is allowed then the spec should say that
specs do not have a time-based nature to them, which makes them non-ideal for on-the-fly validation
they can say what the data should look like when it is “compete”, but intermediate states where you’re trying to validate individual fields just don’t apply
so I am having trouble seeing why you’d want a key with a nil value as opposed to a missing key.
you’re saying (`s/keys :req [:x])` and then worrying that the spec fails because the required key is missing?
in the case of a form (the way the form validation is written) the individual fields can cover the
keys case…this isn’t a spec of data flow through function calls…each field has tri-state, and each field can be checked…what is
fs/mark-complete! marks all declared fields as complete, even if they’re actually not in the props. So, they are getting validated against specs as having nil values. I generally don’t have fields which could potentially be nil (due to the nature of Datomic).
I’m just using mark-complete on the root form, it’s convenient for large forms with a lot of subforms, to mark complete on “save” button press.
please don’t mix “convenient” with operational correctness.
mark-complete lets you say exactly what you consider complete (one at a time, or all at once)…you choosing not to say is a convenience, but is not a limitation. Using that in reduce or doseq is trivial
but if you do want to consider
nil a legal value, then I’m glad to take a PR for a pluggable
Well, “convenient” was a wrong wording, sorry. I need to mark all present fields as complete, but mark-complete marks all declared fields.
Sure, I’m fine with writing the helper (actually I’ve already done it before the discussion), just wonder whether I’m misunderstanding something.
you’re right that mark-missing does expose an opinion about
nil punning that isn’t necessarily consistent…but then since when is
nil punning consistent in Clojure? 😜
it is a personal pet peeve of mine, so I feel your pain, but I fear there is no universal fix
if I had the time, I would have already forked clojure and fixed error messages and crashes on nil punning 😜
and then there’s the “select your poison” for nil as in:
map…this is just more of that. sometimes you just need an option
Yeah, there’s pretty much of it in the core, but we’re kind of all in the same boat and everybody is used to those things, whereas when you go to some 3rd-party library you don’t really know what to expect, so kinda like learning the new language. Thanks for your time, it’s been insightful!
@tony.kay jfyi it turned out that approach with not marking absent fields as complete makes the validation of the root form into a constant
:unchecked state, cuz
merge-validity has these rules:
so I backed off to re-implementing
* :unchecked :valid = :unchecked * :unchecked :invalid = :unchecked
no-spec-or-valid?to check for
(contains? props key); otherwise I’d basically re-implement half of the form state logic