Hello. I'm looking forward to use malli in a project and will be actively learning about it in the next days 🙂

hiccup:

[:schema
 {:registry
  {"Order" [:map
            [:items [:vector [:enum "SIM" "SAM"]]]
            [:delivery [:enum "letter" "email"]]]
   "SimDeliveryRule" [:fn {:error/message "If the order only includes a SIM card then the delivery method may be "letter"."
                           :error/path [:delivery]}
                      '(fn [{:keys [items delivery]}]
                         (or (not= items ["SIM"])
                             (= delivery "letter")))]}}
 [:and "Order" "SimDeliveryRule"]]

{:type :schema
 :registry {"Order" {:type :map
                     :entries [[:items {:type :vector
                                        :items {:type :enum
                                                :values ["SIM" "SAM"]}}]
                               [:delivery {:type :enum
                                           :values ["letter" "email"]}]]}
            "SimDeliveryRule" {:type :fn
                               :error/message "If the order only includes a SIM card then the delivery method may be "letter"."
                               :error/path [:delivery]
                               :value '(fn [{:keys [items delivery]}]
                                         (or (not= items ["SIM"])
                                             (= delivery "letter")))}}
 :value {:type :and
         :values ["Order" "SimDeliveryRule"]}}

Hello there! Malli is great. A question regarding function validation (a.k.a => ): Is there a way to automatically validate that all function calls are made with proper args during development time?

@viebel More info here: https://clojurians.slack.com/archives/CLDK6MFMK/p1619006445487300

Thank you @borkdude!

Given that instrumentation is not yet there in malli, what’s the common use case for :=>?

“Only” generative testing?

It's a good question, I've also wondered myself.

At least you can generate some clj-kondo type hints with it =)

I just tried clj-kondo type hints and it’s awesome. A question related to that: where is the appropriate place for putting the (mc/emit!) function call?

Maybe in "component system du jour" start/reset?

I didn’t know you were speaking french. I don’t have any component: I am writing a library

I am also wondering how the emitted config from the library is going to be integrated in the application that uses the lib

you probably shouldn't do this in your library, it's something an end user should do

Maybe emit it as part of a pre-commit hook or something

why wouldn’t my library be responsible for emitting clj-kondo config for the function it provides?

You can do that, but you should just commit that config into git and not generate it at runtime

clj-kondo has a mechanism to pick up on configs from libraries

Described here: https://github.com/clj-kondo/clj-kondo/blob/master/doc/config.md#exporting-and-importing-configuration

Nice!

Is there already a script that generates clj-kondo config from project that uses malli (basically that calls (mc/emit!)?

Not sure I could use babashka for that as my library might not be babashka compatible

Malli is not babashka compatible either, so you should use a JVM script / function for this. You could just write a function which you can call with clojure -X my.lib/gen-clj-kondo

Malli is not babashka compatible. That is a sacrilege!

There is an issue / petition to add malli to bb: https://github.com/babashka/babashka/issues/737 Feel free to upvote.

It’s not an easy choice: What’s your opinion on that? Did you upvoted or downvoted @borkdude?

Another question related to malli’s :=> : Is there a way to automatically generate a doc string?

@viebel function instrumentation comes with this: https://github.com/metosin/malli/issues/349

lot of things are still TODO, help welcome

Yeah. @borkdude pointed me to this Github issue.

We are starting to embrace malli at work. Hopefully, we’ll be motivated to help

A question related to maps. Is it possible to specify that some combination of fields are forbidden?

@viebel What made you choose malli over spec or both?

@ikitommi gave us a great talk about Malli at our dev meetup at work 😜

We chose malli mostly because: 1. In malli, schemas are data (not macro required) 2. spec seems stuck. Not sure if spec2 will be compatible with spec 1 3. It’s easier to contribute to malli than to spec

Interesting, thanks for sharing. It seems there are two ways people are choosing libraries: 1) choose core unless ... , because: bundled with clojure (no additional deps), authority (core, cognitect), promoted as "the default" 2) choose community, easier to contribute / freedom, usually more focus/options than core libs

Don’t forget the data driven aspect of malli!

Having a version of spec alpha with a replacement in development for years doesn't exactly inspire confidence.

@viebel In the defn podcast you argued that namespaced (fully qualified) keywords are a vital part of data oriented programming. spec promotes this by having specs bound to global keywords so specs describe meaning without context. Is this aspect sufficiently present in malli?

(btw, I liked the podcast :))

Good question @borkdude. I need to play more with Malli in order to answer this question. (I am so glad you liked it)

Is there a way to spec a map using a key from a registry but having the key non namespace qualified?

[:map {:registry {::id :int}
 [:id ::id]]

The work Jim is doing is maybe interesting for the authors of malli as well