Fork me on GitHub
#malli
<
2020-04-05
>
ikitommi10:04:35

@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

thanks3 4
ikitommi10:04:37

@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
ikitommi10:04:31

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

kwrooijen10:04:36

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.

kwrooijen12:04:21

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.

ikitommi13:04:36

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

ikitommi13:04:58

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

ikitommi13:04:24

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

kwrooijen13:04:30

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

kwrooijen13:04:41

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

ikitommi13:04:16

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

ikitommi13:04:20

(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]}

kwrooijen13:04:07

Ok, thank you for the clarification 👍

👍 4
sudakatux16:04:18

So how can i test malli on a lein project

dcj16:04:04

[metosin/malli "0.0.1-SNAPSHOT"]

sudakatux16:04:31

cool just found it at the same time. Thank u

dcj16:04:28

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