@dcj the key-transformer doesn’t understand the :name. It’s simple transformes all keys, not usefull in your case. You should use normal transformer instead. I created a gist, which might show the needed core for the thing you are looking for, using both named property-driven and a custom transformer options. Hope this helps: https://gist.github.com/ikitommi/5d71fc6b320e996b1ac9c17c4d412b71

@pithyless coming (and loving) Plumatic Schema, I have use the class-like naming: User, Address. Currently porting a Schema-project to use Malli, so the var names existed already. If I would add the schemas to the registry, might want to use qualified keywords: (assoc registry ::user User).

Currently, haven’t added any domain schemas into the registry. is anyone doing that?

Is there an idiomatic way of writing documentation for keys? I can't seem to find anything about that in the README. Currently I have this, which works, but feels very hacky.

just for keys:

(def Human
  [:map
   [:human/name {:description "Human name"} string?]
   [:human/age {:description "Human age"} int?]])

(doseq [[k p _] (m/map-entries Human)]
  (println k "->" (-> p :description)))
;:human/name -> Human name
;:human/age -> Human age

for values:

(def Human
  [:map
   [:human/name [:and {:description "Human name"} string?]]
   [:human/age  [:and {:description "Human age"} int?]]])

(doseq [[k _ s] (m/map-entries Human)]
  (println k "->" (-> s m/properties :description)))
;:human/name -> Human name
;:human/age -> Human age

or:

(def Human
  [:map
   [:human/name [string? {:description "Human name"}]]
   [:human/age  [int? {:description "Human age"}]]])

(doseq [[k _ s] (m/map-entries Human)]
  (println k "->" (-> s m/properties :description)))
;:human/name -> Human name
;:human/age -> Human age

as Slack history loses all code, wrote a gist: https://gist.github.com/ikitommi/7c26aebf2b0f58d58432c884c8a55b5a

Ahh nice, m/map-entries is what I needed also didn't know the :and was redundant. There are a couple of example that use :and + opts in the README

So would the convention be :description then? Since that was also used by json_schema ?

yes, :title and :description should be used, I’ll add those to README.

(malli.json-schema/transform
  [:map
   [:human/name [string? {:description "Human name"}]]
   [:human/age [int? {:description "Human age"}]]])
;{:type "object",
; :properties #:human{:name {:type "string", :description "Human name"},
;                     :age {:type "integer", :format "int64", :description "Human age"}},
; :required [:human/name :human/age]}

Ok, thank you for the clarification 👍

Hi

So how can i test malli on a lein project

?

[metosin/malli "0.0.1-SNAPSHOT"]

cool just found it at the same time. Thank u

@ikitommi Thank you for the gist, that is super helpful! You provided two different examples, named property-driven transformations and named transformations, ATM I think I like the named transformations more, but will mull it over... The named transformations version of postgres-transformer answered further questions I had about how to use :complle Would it be a good/interesting idea to store transformers like these in the options of the schema? If so, then presumably they could be accessed later when needed for encode/decode calls....