Fork me on GitHub
Ben Sless13:02:29

Conundrum: how can we make sure a user's pred implementation in custom simple schema is correct? Is it enough that it returns truthy value, or is boolean strictly required? The validator doc string guarantees it returns a function which returns a boolean, but it's pretty easy to violate this. Thoughts?


clearly, the only solution is a self-describing meta-schema for all Malli schemas 😉

Ben Sless14:02:10

AND malli dev instrumentation running in the background to catch everything

Ben Sless14:02:20

That's not a bad idea, btw

Ben Sless14:02:33

A hassle, but could work


thanks to Thomas Heller, I was able to simplify the implementation of clj-kondo support in cljs (this supersedes my prior PR for this) this also updates the general instructions for use with cljs to use preloads which vastly simplifies dev vs release config

🎉 4

This is brilliant!! I'll check it tomorrow 🙇

woohoo 2

Very cool, thanks for working on this! I'm not currently doing much CLJS work, but I remember there were some rough edges in getting the dev experience right.


for sure! I've definitely learned a ton about shadow-cljs and the cljs compiler in general working on this. I think the big improvement since the early implementation is instrumenting at runtime (also a T Heller suggestion :) ) that happened with this PR it's more deterministic as you're not having to think about what is a macro and what is not

Ngoc Khuat16:02:34

Hi guys, the error/fn key takes a function with 2 arities, what is the second argument for?


Hi, how can I make a schema which encodes a boolean to a string and vice versa? I tried:

(def int-boolean-schema
   (fn [_ _]
     {:type :int-boolean
      :type-properties {:decode/string
                        (fn [s]
                          (when-not (clojure.string/blank? s)
                            (get {"0" false "1" true} s)))
                        (fn [v]
                          (prn "val" v)
                          (if (true? v)
Decoding and encoding true works as expected, but encoding false returns nil without entering the :encode/string functions.
;; correct:
(m/decode [:int-boolean] "0" mt/string-transformer)
=> false

;; correct:
(m/decode [:int-boolean] "1" mt/string-transformer)
=> true

;; correct:
(m/encode [:int-boolean] true mt/string-transformer)
=> "1"

;; wrong, it should be "0":
(m/decode [:int-boolean] false mt/string-transformer)
=> nil


Shouldn't this work?

(m/schema [:map {:registry {:my/int [:int {:doc "My int, it's very special"}]}}
           [:key [:my/int {:foo "bar"}]]])
throws invalid schema exception
   {:type :malli.core/invalid-schema,
    :message :malli.core/invalid-schema,
    :data {:schema [:int {:doc "My int, it's very special"}]}}
If I remove the properties from either the registry or the map type it's fine. Maybe properties should be merged?


I think I ran into something similar before (I didn't figure out why it fails yet):

(m/schema [:comment {:some :prop}] 
  {:registry (merge (m/default-schemas) {:comment :int})})
=> [:int {:some :prop}]
does not work:
(m/schema [:comment {:some :prop}] 
  {:registry (merge (m/default-schemas) {:comment [:map [:a :int]]})})

Execution error (ExceptionInfo) at malli.core/-fail! (core.cljc:138).
:malli.core/invalid-schema {:schema [:map [:a :int]]}


I suspect stepping through malli.core/schema with these inputs will shed some light on this. I'll take a look when time permits.


I ran into this again and looked into what's going on. have a fix here:


so it isn't supported to use the vector form in the registry. Will need to change strategies in our apps to handle this desired behavior


one idea is to use :schema

(m/schema [:schema {:some :prop} :comment]  
  {:registry (merge (m/default-schemas) {:comment [:map [:a :int]]})})


also found that add a :ref works

(m/schema [:map {:registry {:my/int [:int {:doc "My int, it's very special"}]}}
           [:key [:ref {:foo "bar"} :my/int]]])