Not having a global registry has a downside though. Let’s say some library introduces a new Schema protocol implementation. Then someone uses that in schemas in namespace X. With Spec when you load the namespace you automatically gain all specs in there with all the required bits and pieces to make it all work. But with the way Malli is set up, if something is using a custom :datetime schema, then all the users of that thing must invoke all the Malli functions with an opts map where :registry is set to the default one with all the extensions added. If the calls to m/validate and such are burried inside a third party library, then that library must provide a way for you to pass the registry to be used otherwise, you cannot use any new schema types except the ones defined in malli.core

Also I’d like to ask, what is the policy regarding non-serializable content in schemas. I see that some examples include opts map where you have keys like {:decode/string some-fn} which isn’t really serializable

This is meant vis-a-vis developing own schema implementations… should I disallow non-serializable options?

@roklenarcic you can always define the library schemas as Vars, the first value in the Schema vector syntax can be an instance of IntoSchema.

(def date-time (reify IntoSchema ...))

(m/validate date-time (java.time.DateTime.))
; => true

the work like components on Reagent.

so I can also do `[datetime “format”]?

policy on non-serializable: up to the user. There is an issue about making an utility that checks if a schemas can be fully persisted or not. One can put that into project tests.

yes

thanks that is very helpful

I mean any schema that specifies decode/encode implementation cannot be persisted?

(defprotocol IntoSchema
  (-into-schema [this properties children opts] "creates a new schema instance"))

quote the functions and they can be serialized.

(require '[malli.core :as m])
(require '[malli.edn :as edn])

(-> [:and
     [:map
      [:x int?]
      [:y int?]]
     [:fn '(fn [{:keys [x y]}] (> x y))]]
    (edn/write-string)
    (doto prn) ; => "[:and [:map [:x int?] [:y int?]] [:fn (fn [{:keys [x y]}] (> x y))]]"
    (edn/read-string)
    (doto (-> (m/validate {:x 0, :y 1}) prn)) ; => false
    (doto (-> (m/validate {:x 2, :y 1}) prn))) ; => true
;[:and 
; [:map 
;  [:x int?] 
;  [:y int?]] 
; [:fn (fn [{:keys [x y]}] (> x y))]]

ah.. but then the code processing the value has to call eval or something on it?

it uses sci , a small interpreter. So it works on JVM, ClojureScript & GraalVM, no eval needed

it’s <10kb on cljs.

https://malli.io/?value=%7B%3Ax%201%2C%20%3Ay%202%7D&amp;schema=%5B%3Aand%0A%20%5B%3Amap%20%5B%3Ax%20int%3F%5D%20%5B%3Ay%20int%3F%5D%5D%0A%20%5B%3Afn%0A%20%20%7B%3Aerror%2Fmessage%20%22x%20should%20be%20greater%20than%20y%22%7D%0A%20%20(fn%20%5B%7B%3Akeys%20%5Bx%20y%5D%7D%5D%20(%3E%20x%20y))%5D%5D

that’s all normal code, no clojurescript compiler used in the demo.

sorry, I should be clearer. If my custom datetime schema has an option :formatter which someone puts the value of DateTimeFormatter/ISO_INSTANT

e.g. “production code”

oh, that. can’t serialize that.

if I quote this, I get a symbol

it could have :format option, which could be string?

the latest version of sci supports Java reflection, if you bring this class in with the :classes option. but that won't work in CLJS of course

sure, but you cannot specify instant formatter by giving a string

but you can use reader conditionals for that maybe

specifying something like “yyyy-MM-dd” then telling it to format an Instant object will fail

{:format :iso_instant} maybe?

time is hard to get do in a portable way anyway.

My current idea is to support everything

so if someone puts a formatter instance there, then I will use it

string or a (predefined) keyword?

.. or a class, which is used.

but then they lose serializability, but that’s on them

ok… this was very helpful

one thing there could be is to have a startup-time altering of a registry. via JVM options for example. It would be explicit, but still global.

plan is to pull schema defn and fn syntax helpers, can’t pass easily any custom options/registry there.

(m/defn plus :- int? 
  [x :- int?, y :- int?] 
  (+ x y))

to support something like [:json-schema {:type "string"}] schema would require some way to change the one registry. could just be the var reference (`[json/json-schema {:type "string"}]`), but could be a JVM property to bootstrap some extra schemas into the registry… not sure if thi is a good idea

… or just malli.evil ns, which has all the public functions of other namespaces, but with the default-registry as an atom.

(require '[malli.evil :as evil])

(evil/register! ::int int?)

(evil/validate ::int 1)
; => true

… or a JVM option to define the default-registry implementation. by default, it points to the immutable map, but could be swapped to atom impl. Bad Idea 🙂