I just had a pleasant experience during my team's standup. I'm working on code that depends on some PostgreSQL tables with JSON columns. We're migrating to a new set of tables given new needs. In that change, we're also moving some data from within the old JSON structure out into normal table columns. To give insight into my work, I generated schemas for the JSON with malli.provider/provide, and shared the generated malli schemas with my team. Explaining malli took 30 seconds and one example:

"Malli is a schema system for JSON."

"This JSON:"

{"x": 1,
 "name": "something"}

"Gets this schema:"

[:map
 [:x int?]
 [:name string?]]

If I want to add a custom tag to the registry, to support something like [:string {:min 1, :max 10}] - do I need to create a brand new IntoSchema (e.g. modeled similarly to m/fn-schema on -leaf-schema but with support for properties) + define a custom mg/-generator ? Or is there some way I can reuse more of the existing malli machinery?

@pithyless there are not many helpers in the core currently, but reifying the IntoSchema is a good way to do those. I think all the separate concerns (JSONSchema, Generators, Providers etc) should have a supporting protocol so one could easily satisfy all the concerns with one reify-block. Currently requires protocol + set of multimethods. For core stuff, it’s intentional to have the mm’s: the core remains small as it doesn’t have to know much/anythning about the other concerns.

also, there is a PR for discussion about swapping the default registry - to support spec-like mutable registries.

I think if there would be a set of type-kind-of schemas in malli core, one would not need the current core predicates at all. e.g. :string instead of string? , :date-time instead of inst etc.