https://github.com/metosin/malli/issues/958

instrumentation is checking value but the errors thrown don’t include/display the explanation

I guess it’s either not possible or need a specific setup

I can workaround by capturing input values in REPL and using m/explain but the jvm DX is so nice I’d love to have it in the node env as well

not using in node, so just all 👂s with this one.

I just tried it out with a small :node-script target and just need to change the default report argument from thrower to reporter: https://github.com/metosin/malli/blob/2a5fc9a6bbf1360881104df2974dc319d3d17431/src/malli/dev/cljs.cljc#L29 in shadow-cljs.edn:

:instrument-node {:target :node-script
                  :output-to "out/instrument_node.js"
                  :main malli.instrument-node/main }

(ns malli.instrument-node
  (:require
    [malli.core :as m]
    [malli.dev.pretty]
    [malli.dev.cljs :as dev]))

(defn plus [x] (inc x))
(m/=> plus [:=> [:cat :int] [:int {:max 6}]])

(defn minus
  {:malli/schema [:=> [:cat :int] [:int {:min 6}]]}
  [x] (dec x))

(defn main [& args]
  (println "in main"))

(dev/start! {:report (malli.dev.pretty/reporter) :skip-instrumented? true})

(comment
  (m/function-schemas :cljs)
  (plus "hi")
  (minus 5)
  )

-- Schema Error ------------------------------------------------------------------------------------

Invalid function return value:

  4

Function Var:

  malli.instrument-node/minus

Function arguments:

  [5]

Output Schema:

  [:int {:min 6}]

Errors:

  {:in [], :message "should be at least 6", :path [], :schema [:int {:min 6}], :value 4}

More information:

  

----------------------------------------------------------------------------------------------------

not sure about "instrumentation is checking value but the errors thrown don’t include/display the explanation" I'm seeing even with the thrower I get the same report in the repl output it just doesn't show in the terminal

thanks @U051V5LLP you are right. I need to apologise because I just realised it was my own logging config that was not displaying the explanation in the node env

it is working as you demonstrated for me too

that said, I have uncovered a challenge in this scenario. I have a try/catch block that is catching the exception thrown by malli.core/-fail

in the catch block I’m trying to log the explain. it’s not in the exception data. I’ve tried using m/explain using the :schema and :inputs data from the exception but it returns nil. can’t figure out why

here’s a repro….

(mx/defn ^:malli/always combine :- :string
  [{:keys [prefix suffix]} :- [:map
                               [:prefix :int]
                               [:suffix :string]]]
  (str prefix " -> " suffix))

(md/start!)

(try
  (combine {:prefix "1" :suffix "a"})
  (catch :default e
    (let [{:keys [args schema]} (:data (ex-data e))]
      (malli.core/explain schema (first args)))))

the explain in the catch block returns nil in the node env

@ikitommi @U051V5LLP any suggestions on this? I now suspect either mx/defn or ^:malli/always as the problem because they were necessary to reproduce this

no worries @U0510KXTU was going to say if you have a repro.., so thanks : ) yea I think the issue would be in mx/defn implementation. From a quick scan for any differences vs what dev/start! is doing it looks like the mx/defn does not pass the :report option to -instrument https://github.com/metosin/malli/blob/30a2176f1893602d8a948ef3103fde91ec5fd638/src/malli/experimental.cljc#L56C39-L57C84 and those reporters are what add the :data and :type https://github.com/metosin/malli/blob/30a2176f1893602d8a948ef3103fde91ec5fd638/src/malli/dev/pretty.cljc#L88 to the ex-info map so could try adding that to the mx/defn implementation

also looks like both code paths in mx/defn (with and without malli/always) don't add :report

Brilliant. I might try fixing this. Will PR if I do

@ikitommi I just tried to fix mx/defn but I get lost in the connections between mx/defn calling -instrument and how that data flows to pretty. could you give me a nudge in the right direction about what needs to change for pretty to have the data it needs from mx/defn? I’ll test the fix locally once it is working and will PR

tbh this shows my lack of macro-foo. I tried requiring pretty into the experimental ns and then creating a pretty/thrower to use in the macro body. but fails at runtime because I haven’t correctly spliced in the thrower fn.

gpt4 tells me that cljs macros can’t use fns because they aren’t constants. at this point I’ll be guessing so I’ll wait for some cljs macro Jedi master instruction

don't know if there's a better way, but you could do

[:fn #(satisfies? MyProtocol %)]

Cool! Works for me. Thanks!

I asked a similiar question a few months ago, this is what I have in a common library now:

(defn protocol-schema
  "Returns a malli schema that ensures the value satisfies the given protocol."
  [prot]
  (m/-simple-schema
   {:type            (:on-interface prot)
    :pred            #(satisfies? prot %)
    :type-properties {:error/fn (fn [error _] (str "Expected value to satisfy " (:on-interface prot) " protocol."))}}))

It MAY be worth considering what happens with protocols being redefined, and change that to take a symbol that is resolved in the pred....

I saw may because I have not confirmed my hunch that it makes my schema a little delicate in the face of protocol redefs

I'm not sure I understand what is the question here.

lol i'm sorry

i think the question is, what's the best way to have a given malli schema represent both input to validate and internal model?

is that possible (or desirable)?

sure, m/coerce , m/coercer , m/assert or just function schemas:

(mx/defn no-op :- PayloadSchema [p :- PayloadSchema] p)

do you want just dev-time validation or also runtime validation?

both. i wired up a ring middleware which calls m/validate on a provided malli schema. i could call m/coerce, but that's not cached and i'm hoping to avoid writing manual (def ObjCoercer (m/coercer ObjSchema)) for every schema.

maybe i could just write a coercer cache myself

wait what, which routing library are you using? Reitit at least has built-in mw for request and response coercion with cached coercer.

We're using Compojure and we have a homespun url-specs system that's very reminiscent of Reitit but predates it by a while

i've suggested moving to reitit, but we have roughly 350 endpoints and switching is hard lol

Cached now resolution in compojure is really hard, things like context bodies are resolved for each request at runtime

compojure or compojure-api?

just compojure

we're not caching anything in the compojure routes at all, we have a separate map that is filled with entries like this:

[:get "/v0.1/public-invite-codes/:public-invite-code"] {:response #'invites/public-get-response}

(when payload-schema (validate-payload route payload-schema payload)) etc

it's pretty simple but does the trick