Configuring the Default Registry

[ikitommi]

Background

Currently, Malli defaults to immutable registry. Immutability makes it simple, no surprises (of the registry changing over time, causing hard to debug problems) and there is only stuff user has explicitly defined in it.

But, in real life, this is not easy: using custom schemas mean you need to construct a new immutable registry with the schemas in and pass it in to every method in malli api. This is a lot of boilerplate and is prone to errors.

One can also override the default registry and this is what most of the projects I've done have used. But - it requires extra JVM property & Compiler option in CLJS. It's too invasive.

Problem Statement

There should be easy way to start using extra schemas as modules, e.g. all malli.time schemas

Alternatives

1. don't do anything, Immutable is Simple, who wan't Easy anyway?
2. allow swapping the default registry without JVM/Compiler options
3. mutable registry by default, like spec, whoever can register whatever they want

1) don't do anything, Immutable is Simple, who wan't Easy anyway?

Immutable is GOOD, and one can use schema instances already instead of schema types (and registry lookup):

(def MyUUID (m/-simple-schema {:type :uuid, :pred uuid?}))

(m/validate [:map [:id [MyUUID (:title "id"}]]] {:id (java.util.UUID/randomUUID)})
; => true

2) allow swapping the default registry without JVM/Compiler options

e.g. swappable by default, there could be a "strict" mode not allowing this (for the paranoid).

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

;; swap the default registry, without tears
(mr/set-default-registry!
  (mr/composite-registry
    (malli.core/default-schemas)
    (malli.time/schemas)
    (malli.util/schemas)))

(def User
  (m/schema
    [:map
     [:name :string]
     [:birthdate :local-date]]))

(m/validate 
  User 
  {:name "tiina"
   :birthday (java.time.LocalDate/of 1980 05 02)})
; => true

This would also allows managed mutability:

(def ^:private registry* (atom {}))

(def register! [k s] 
  (swap! registry* assoc k (m/schema s))

(mr/set-default-registry!
  (mr/composite-registry
    (malli.core/default-schemas)
    (malli.time/schemas)
    (malli.util/schemas)
    (malli.registry/mutable-registry registry*))

;; add stuff, just you
(register! ::id :int)

3) mutable registry by default, like spec, whoever can register whatever they want:

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

;; require explicitely
(mr/register! (malli.time/schemas))

;; require via side-effects 🤔 
(require '[third-party.library.that.registers.stuff])

;; add stuff
(mr/register! ::id :int)

;; redefine stuff 🙀 
(mr/register! ::id :string)

Elsewhere

Related issues:

• Move core protocols to new ns #546
• Configure default registry in less invasive manner #488
• Custom Default Options #228
• Better support for dates #49

Related PRs:

• DRAFT: Default options #235

[bsless]

I lean towards mutable registry by default, maybe with a caveat that individual schemas can't be registered, only entire "modules", thus forcing users to load their model and not just mutate things "irresponsibly"
If you want to avoid loading the entire registry (for cljs, etc) perhaps you can add a lazy initialization system

[bowbahdoe]

I think the core issue is that the default registry is "privileged" over user provided ones.

Because passing fewer arguments uses the default and no one wants to pass more arguments there is a pressure to have the default registry be all things to all people.

One alternative I'd like to add to the mix is some convenience for users to re-export all the functions that would be the entry point of a custom registry with their own registry "partial"-ed in.

It would be the users responsibility to merge whatever library schemas they want into their registry, and they would access malli's functionality via com.company.malli.

[ikitommi]

Thanks for the comments.

I think this is the expression problem: one the other hand, we have a big number of schema applications (creation, validation, explaining, parsing, transforming, json-schema, generation, inferring, plantuml, ...) and then we have a set of Schemas that have implementations for those applications.

@bowbahdoe The convenience funtion(s) to would have to cover all applications. e.g. com.company.malli, would have to have to-json-schema, generator, to-dot etc.

I'm today in favour of option 2 (but far from being happy with it), because:

Good

1. it's explicit. There is one point in your application where you need to describe how to use malli, also serves as documentation, "we are supporting the following (sub)set of schemas". And apps already have a one place to start (to set up logging, integrant/component stuff, react rendering etc)
2. mostly no surprises, there is no global m/register! to publish schemas as side-effects when loading namespaces (like spec does, once you allow this for sake of being easy, all bets are off from understanding what's in the registry and why)
3. it promotes a good practise of providing library schemas as maps of type->Schema that are easy to pull into your application as a bundle. Also, the schema definitions could be part of the normal namespaces -> without pulling the schemas in, the core is DCEd automatically as no-one is referencing the code. Big win.

Bad

1. there is more work to pull in library schemas (by default, need to pull them manually once per library?) => there could be a method to scan all namespaces and pull those in, using malli.dev/start for example... 🤔
2. if a library provides the schemas as a function of type->Schema and there are functions that would like to use the schemas, how do you do that? basically one would need to reference the schemas directly, effectively forcing them to be loaded. Also, how would one reference those?

[bsless]

I think bad.2 would force converging on an extension API
Another option for swapping the default registry can be a dynamic variable. that way you can both set and conditionally bind it, but that seems evil.
Also integration with DI frameworks is interesting, which exposes the final approach, a "schema factory" which takes the default options, including registry, which is used for compiling all schema and worker objects. That way you have it "as a value" with no mutability

[ikitommi]

I like the idea of closing everything outside of dev-time. For CLJS, this would also resolve the initialisation perf issue: At dev-time, one could use all schema available transformation tools (which have a runtime performance cost), but once everything is built, the registry could be emitted as Schema AST, to have fast & lazy instantiation.

[ikitommi]

maybe: #583.

[ikitommi]

what if the schema system always started as empty?

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

(m/validate :int 1)
; =throws=> :int not found

;; setting the default registry, both do the same
(m/set-default-schema-registry!)
(m/set-default-schema-registry! (m/default-schemas))

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

[ikitommi]

Going with initial 2, via #583. Keeping this open as there is still options on how to move forward (closing everything, starting from empty registry etc.)