Fork me on GitHub

@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:

thanks3 4

@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).

👍 4

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


I was thinking of doing this. I want to create UI elements based on the type of the schema. My initial thought was to use properties, but creating a registry could also be a valid option. But I'm still learning all the ins and outs of Malli though.


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
   [: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
   [: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



(def Human
   [: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


Ahh nice, m/map-entries is what I needed simple_smile 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.


   [: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 👍

👍 4

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....