This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-01-12
Channels
Nice, date-support is on malli backlog, need to figure out a way to make it work with cljs too.
Generally, transform operations do not validate that input passes the validator first, which is good for performance, but when you have an operation like :or
how do you know which branch of OR to use for transformation? Currently you try every branch as transformation and return the first result that changes the value.
however this leads to this:
(m/encode [:or
[string? {:encode/string #(.toUpperCase %)}]
[int? {:encode/string str}]]
1
mt/string-transformer)
Execution error (IllegalArgumentException) at com.github.roklenarcic.malli-inline/eval17000$fn (form-init15839185010501867114.clj:2).
No matching field found: toUpperCase for class java.lang.Long
none of the built-in transformers will validate input and return the value itself if not the right type, which would make :or work correctly in this regard
The only realistic way to fix this would be to have :or
do validate for each branch until it finds one that validates and then run that transform. This would perform as expected, I can prepare a PR.
@roklenarcic sounds right to me to select branch based on validate
another possible bug
in about 5 different explainer
functions in malli.core you have distance (if (seq properties) 2 1)
if properties is missing then distance should be 1
the problem is that if someone puts {}
as properties, then (seq properties)
is false
and it will say distance 1, when the form has [symbol {} children]
so the path is possibly wrong… I don’t know what the semantics of path is exactly
but you see what I’m getting at… (seq properties)
is nil for nil
and {}
, not good for counting elements in form
Will need malli at a project starting tomorrow, so good reason to push out first alpha too
should the schemas allow nil
children? e.g. [:and int? nil pos-int?]
. Currently :map
allows, composite schemas don’t.
also, currently:
(m/form [:and {} int?])
; => [:and int?]
(m/properties [:and {} int?])
; => {}
should empty properties be removed (set to nil
) already when schema is created from AST?
after that:
(m/form [:and {} int?])
; => [:and int?]
(m/properties [:and {} int?])
; => nil
my suggestion:
• allow nil
child schemas in all core schemas: easy to create programmatically (e.g. [:map [:x int?] (if require-y [:y int?])]
)
• treat empty properties as nil
, allows (`[:map (if close-maps {:closed true}) [:x int?]]`)
sure, sounds sensible
can explainer fn return null? I thought it must return acc
I agree all core schemas should behave identically; I would suggest not ignoring nil children, which gives more obvious semantics in cases like this: [:and int? nil pos-int?]
(this would always be false, instead of implementing a special-case for nil that behaves differently than regular "falsey" semantics in Clojure). In the map example, I find it more intuitive to use malli.util/merge
semantics to describe programmmatic optionality: (malli.util/merge [:map [:x int?]] (if require-y [:map [:y int?]]))