malli 2021-08-16 | Slack Archive

pithyless08:08:21

I'm working with the malli schema functions (the new dev error reporting is nice!) and I seem to be at a crossroads: 1. If I choose to use m/=> at the top-level: a. I need to an explicit dependency on malli (not generally a problem with applications, but this is probably a no-go for libraries) b. I cannot use non-standard registry schemas, since it is evaled at compile time. c. I think even if I could force some preload logic to make sure my global malli registry is updated before other namespaces are loaded, this is both prone to errors and probably would still not work with external tools that work per-file (clj-kondo, etc) 2. If I choose to use :malli/schema metadata: a. I am free to include it optionally without directly requiring malli b. I can use non-standard registry schemas c. The malli.dev/start! does not pick up var changes (need to force a refresh) d. The metadata approach sometimes makes the function feel "verbose". This is a obviously a subjective feeling, but if the specs are verbose and the function body is short, sometimes the separate m/=> looks nicer. Because of the problems with (1), I'm thinking of still focusing on (2). I can workaround (2c) and perhaps (2d) can be mitigated in certain cases with a (def foo-schema [:=> ...]) and then using (defn foo {:malli/schema #'foo-schema} ..) ?

pithyless08:08:59

Posting these observations, in hopes that someone can set me straight on my misunderstanding; or perhaps suggest a better approach? :)

ikitommi09:08:16

#Also sent to the channel

• 1b&c -> this should be resolved somehow, please write an issue • 2c -> can be fixed (look up for var changes automatically) • d -> true that what might help if malli could pick up the function schemas from the actual functions behind the vars. it would allow one to say:

(defn kikka [])

;; just clojure
(defn => [v schema]
  (alter-var-root v vary-meta assoc :malli/schema schema))

;; add a function schemas without deps to malli
(=> #'kikka [:=> :cat :any])

;; reading from function
(-> kikka meta :malli/schema) ; => [:=> :cat :any]

pithyless09:08:41

That looks promising; I will try it out today and submit an issue later. Thanks!

ikitommi09:08:16

replied to a thread:I'm working with the malli schema functions (the new dev error reporting is nice!) and I seem to be at a crossroads: 1. If I choose to use `m/=>` at the top-level: a. I need to an explicit dependency on malli (not generally a problem with applications, but this is probably a no-go for libraries) b. I cannot use non-standard registry schemas, since it is evaled at compile time. c. I _think_ even if I could force some preload logic to make sure my global malli registry is updated before other namespaces are loaded, this is both prone to errors and probably would still not work with external tools that work per-file (clj-kondo, etc) 2. If I choose to use `:malli/schema` metadata: a. I am free to include it optionally without directly requiring malli b. I can use non-standard registry schemas c. The `malli.dev/start!` does not pick up var changes (need to force a refresh) d. The metadata approach sometimes makes the function feel "verbose". This is a obviously a subjective feeling, but if the specs are verbose and the function body is short, sometimes the separate `m/=>` looks nicer. Because of the problems with (1), I'm thinking of still focusing on (2). I can workaround (2c) and perhaps (2d) can be mitigated in certain cases with a `(def foo-schema [:=> ...])` and then using `(defn foo {:malli/schema #'foo-schema} ..)` ?

(defn kikka [])

;; just clojure
(defn => [v schema]
  (alter-var-root v vary-meta assoc :malli/schema schema))

;; add a function schemas without deps to malli
(=> #'kikka [:=> :cat :any])

;; reading from function
(-> kikka meta :malli/schema) ; => [:=> :cat :any]

Tiago Dall'Oca09:08:58

Hello there

Tiago Dall'Oca09:08:45

I'm trying to create a parser for converting malli's schemas to DTS files (typescript's type definitions file). One of the situations I'm running into is reading malli's schemas correctly, as they're plain data structures with semantic meaning, so I have to check for some options maps when parsing :map or even cases like https://github.com/metosin/malli#qualified-keys-in-a-map. I was thinking of writing a https://github.com/metosin/malli#parsing-values for helping me out with that, but maybe it already exists? Or is there an easier way?

❤️ 3

💯 6

ikitommi09:08:41

Sounds great, looking forward to this! You can as m/children and m/properties from a Schema instance. The first one returns the parsed enty-tuples [key properties value] if that helps.

👍 3

Tiago Dall'Oca12:08:17

m/children is exactly what I was looking for! Thanks :D

richiardiandrea15:08:58

Will monitor this - we have TypeScript as frontend and indeed sharing the API specs would be super cool 🙂

ikitommi17:08:18

Btw, the JSON Schema converter is a good example of generic transformer of malli->xyz, https://github.com/metosin/malli/blob/master/src/malli/json_schema.cljc

👍 6

richiardiandrea22:08:14

@U4U6BDQTE how far did you get with this project? Do you need/would you accept any help? 😄

Tiago Dall'Oca22:08:48

hey there