Fork me on GitHub
#malli
<
2021-03-13
>
ikitommi07:03:31

::m/default for :multi merged in master:

(def valid?
  (m/validator
    [:multi {:dispatch :type}
     ["object" [:map-of :keyword :string]]
     [::m/default :string]]))

(valid? {:type "object", :key "1", :value "100"})
; => true

(valid? "SUCCESS!")
; => true

(valid? :failure)
; => false

💯 4
ikitommi07:03:04

Maybe the same could be used for extra keys in maps? (https://github.com/metosin/malli/issues/43)

borkdude09:03:20

@ikitommi I was trying (for fun) to write a core.match like thing with malli. So {:a ?x :b 1} would match on {:a 2 :b 1} and parsing would give you back {?x 1}. This is currently a bit difficult since you cannot change how keys are named in the parsed output from map schemas, can you?

borkdude09:03:28

So I would generate a schema like {:b [:= 1] :a :any} but then the parsed output loses the name ?x

borkdude10:03:10

Can I influence how things get parsed using an extra predicate similar to s/and in spec?

(m/parse [:map [:a [:and :any
                         [:fn (fn [x]
                                ['x? x])]]]]
              {:a 1})

ikitommi10:03:00

not atm, parsing could have it's own property key for this, e.g. [:map {:parse ...} ...]. Internally, could be interceptors, so one can do easily pre, post & schema-based parsing with that.

ikitommi10:03:46

We discussed with @nilern about combining internally parsing, explain and transform. They are now mostly (optimized) duplicates of each other.

ikitommi10:03:06

map keys -> could done with same mechanism. Add custom parse tags to keys as properties and hook a post-parse fn to rename the keys. Or do, whatever.

ikitommi11:03:09

ported the plumatic-style inline schemas for 0.3.0, it kinda works, but no tests and not happy with the original (string-based) error reporting. renamed to ns to malli.experimental.schema as it might not be part of the malli core library. any thoughts on this? add tests, cleanup and ship as experimental add-on?

👍 7
ikitommi11:03:42

the defn now emits a function schema into malli function registry and it can be configured to validate always, never or based on a dynamic var - at runtime.

vemv14:03:29

Replied in https://github.com/metosin/malli/issues/125 . Btw I hope I'm not pestering too much - I simply try to make an educated attempt at improving perceived problems (which can last long - for example I use Schema at work and it kinda hurts to use an outdated tech that turned out to not be the best bet)

lmergen13:03:33

what is the validator i can use for 'any collection, no matter the type' ? i don't care whether it's a sequence or vector or set, just that it's a collection. what can i use for this? i wasn't able to find it

lmergen14:03:23

i can use that like [:coll pos-int?] ?

lmergen14:03:28

trying to figure out the best way to do this 🙂

ikitommi14:03:03

sadly, it's just the core predicate, so no child type checking. There is no :coll atm. Would be a oneliner to add

lmergen14:03:12

is there a specific reason why this is not in malli itself? as in, if i would send a PR to add this, would that be useful?

ikitommi14:03:53

no-one has asked, PR welcome (tests included)!

lmergen14:03:08

of course 👍

ikitommi14:03:30

it spans to generator, json schema, human errors etc. But, good examples :)

lmergen14:03:30

thanks, i'll see what i can do

👍 3
lmergen14:03:42

yes it touches a lot of surface

juhoteperi14:03:37

coll? also matches maps, that has some effects on JSON-Schema implementation at least

☝️ 3
ikitommi15:03:38

good point. I guess there is not a predicate for non-map collection.

nilern15:03:01

I imagine maps also having keys can lead to all sorts of confusion when implementing [:coll pos-int?]

nilern15:03:21

What about :sequential?

nilern15:03:58

Oh that does not take sets

nilern15:03:42

Can always do [:or [:sequential pos-int?] [:set pos-int?]]

nilern15:03:29

That does not support seqs though... and now I see nothing else does either.