This is a snippet from when I used shadowcljs to write an 'npm' module in clojurescript - I am calling a core nodejs (net) and an npm dep (protobufjs):

(ns fnrc.core
  (:require ["net" :as net]
            ["protobufjs" :as proto]))

(def schema (atom nil))
(defn load-schema []
  (->
   (proto/load (str js/__dirname "/src/main/fnrc/proto.proto"))
   (.then #(reset! schema %))
   (.catch #(reset! schema (.toString %)))))

(defn load-schema-cb []
  (proto/load (str js/__dirname "/src/main/fnrc/proto.proto")
              (fn [err root]
                (if err
                  (reset! schema (.toString err))
                  (reset! schema root)))))

main thing is in your require area you have to quote the npm/nodejs import (the "from <whatever>" segment in your sample) - the rest would be basic clojure(script) interop for how to chain the functions as are done in your sample - and some of my snippet is not relevant to your Q, it was just the smallest sample I could find (shows promise chaining as well)

even if I replace that with simple spec i.e.

:client-supplied-request/target_date :int/non-negative

doesn't work in what sense? you haven't shown the output you get

I passes the validation even though i pass wrong input

there are several issues in the spec I pointed out, have you fixed those? are you using a different spec now? what is the different spec?

If I replace (spec/def :client-supplied-request/target_date :string/is-valid-date) with (spec/def :client-supplied-request/target_date :int/non-negative) then also it passes the validation with wrong input

what is the wrong input and what is :int/non-negative

(spec/def :int/non-negative is-pos?)

{:target_lpi_as_date_str "fff" :target_enrollment 333}

and what part of that isn't supposed to match?

:target_lpi_as_date_str "fff" 

your spec says the keys are optional and unqualified (:opt-un)

that key isn't in the spec you showed, so spec wouldn't do anything with it

:target_date "fff" 

this is the key

that isn't what you pasted above

are you sure that is the key?

Yes, I just tweaked the actual code to make it simpler

so what is the input?

{:target_date "fff" :target_loss 333}

and what is the spec

(spec/def :client-supplied-request/target_loss :int/non-negative)
(spec/def :client-supplied-request/target_date :int/non-negative)

and what is :int/non-negative

(def is-pos? #(and (nat-int? %) not-nil?))

(spec/def :int/non-negative is-pos?)

those are the keys in the spec, what is the whole spec?

(spec/def :client-supplied-request/client-supplied-targets
  (spec/keys :opt-un [:client-supplied-request/target_loss :client-supplied-request/target_date]))

I am trying to get all the pieces together in one place, because getting the parts here and there separate has resulted in lots of disjointed bits that don't match each other

Not sure if it explains the problem but the definition of is-pos? is wrong, it should be: (def is-pos? #(and (nat-int? %) (not-nil? %))

it doesn't actually matter, because the not-nil? isn't doing anything

nat-int? is already false for nil

Yes but if the input is a nat-int then not-nil? is evaluated and is-pos? returns that

sure, but a function has a truthy value of true

(require '[clojure.spec.alpha :as spec])
(import '(java.util Date))

(def not-nil? #(not (nil? %)))
(def is-valid-date? #(and (string? %) (inst? (Date.))))
(def is-pos? #(and (nat-int? %) not-nil?))

(def is-pos? #(and (nat-int? %) not-nil?))

(spec/def :int/non-negative is-pos?)

(spec/def :client-supplied-request/target_loss :int/non-negative)
(spec/def :client-supplied-request/target_date :int/non-negative)

(spec/def :client-supplied-request/client-supplied-targets
  (spec/keys :opt-un [:client-supplied-request/target_loss :client-supplied-request/target_date]))

(spec/valid? :client-supplied-request/client-supplied-targets {:target_date "fff" :target_loss 333})

is the facts as I understand it, put together in a nice neat package that anyone can paste right into a repl and try out

and spec/valid? returns false there

trying.....

so, either the spec you are sharing is not what you are actually running, or you are misinterpreting results of a larger program, or ...

there was a typo in the key, it worked.

thanks a lot @U0NCTKEV8

Welcome 👋. If you want to cross-post (usually shouldn't be necessary but :man-shrugging:), your best option is to post once, and then link to that in other channels. That directs everyone to the same place to respond. And for long posts like this, it is nice if you first post just your question, and start a thread for extra details and code. You can create code blocks by typing `. That makes your code way easier to read.

Nothing about your code example jumps out as being wrong. You probably want to narrow down where the error is happening.

If you clojure.walk/macroexpand-all, you can see that that destructuring happens in the body of the function:

> (clojure.walk/macroexpand-all '(defn foo [{:keys [a b c]}]))
(def
 foo
 (fn*
  ([p__33970]
   (let*
    [map__33971
     p__33970
     map__33971
     (if
      (clojure.core/seq? map__33971)
      (if
       (clojure.core/next map__33971)
       (.
        clojure.lang.PersistentArrayMap
        createAsIfByAssoc
        (clojure.core/to-array map__33971))
       (if
        (clojure.core/seq map__33971)
        (clojure.core/first map__33971)
        clojure.lang.PersistentArrayMap/EMPTY))
      map__33971)
     a
     (clojure.core/get map__33971 :a)
     b
     (clojure.core/get map__33971 :b)
     c
     (clojure.core/get map__33971 :c)]))))

(defn my-parse [form {:keys [opts keywordize? on-error]}])

Other than that, I don't think it matters that much. You can also go overboard in trying to communicate too much through destructuring (relying on the :or of a destructure is a common example).

thx, in what scenarios do you see the function signature and not the body? API docs?

The function signature (or arglists, there can be multiple for a single function) is used by number of tools. For my personal setup (emacs+nrepl+cider), it shows up as I'm typing.

And as you mentioned, it also gets picked up by several documentation generators.

user> (defn parse [form {:keys [opts keywordize? on-error]}])
#'user/parse
user> (meta #'parse)
{:arglists ([form {:keys [opts keywordize? on-error]}]),
 :line 74,
 :column 7,
 :file "*cider-repl workspace/desk:localhost:60870(clj)*",
 :name parse,
 :ns #namespace[user]}

To me it just looks cleaner in the body but maybe is just my unfamiliarity

this is a context sensitive thing. in my current app all my web resource handlers use destructuring in the function def, but not many other functions in my code do. it's just a convention that i found useful.

In Calva, I see a full function signature, including destructuring, along with doc strings, when I hover the mouse over the name of a function. This tells me which keys my map needs to have, or gives meaningful names to parts of a tuple.

Also sometimes you have a larger map that your function only needs one or two keys from, in this case destructuring (at least as long as it is without :as) also lets the caller know that you will not be messing with the other keys in the map (say a ring request with a ton of stuff and you only care about two headers).

"in what scenarios do you see the function signature and not the body" I think any time I look at a function to find out what it does and how to use it, I want to be able to avoid a deep dive into the body, even though it is right there. I just want a quick synopsis that, again, might spare me digging into the body. Having the destructuring in the function parameter list makes the synopsis a bit richer. But, tbh, many times a function is really expecting a specific control block as a parameter. If there is no :as to communicate that, the code feels a bit obfuscated/clever.

If the caller calls the function with the wrong shape of argument, it can be difficult to know why Sometimes it’s nice while debugging a faulty caller to have the binding in the body where you can set breakpoints or print out values.