I though it might be a dependency problem... I was using a version that came the first on the top of Google search when I was searching for the library and I thought it was the newest one. Thank you very much!

you shouldn't need to add it to your dependencies at all. shadow-cljs already depends on it, so you'll get it anyways

Not supported by the component itself. But you can use a checkbox without a label and just add a label to it via h-box.

Okay thanks a lot

oh, it depends on when it’s evaluated:

(def ^foo x {})  ;; <-- foo is not evaluated
(def x ^foo {})  ;; <-- foo is evaluated

oh, I think this means the metadata’s evaluation is contingent on the evaluation of the form itself. that makes sense

Why does it make sense? Especially given that it differs from Clojure.

Does the example differ between clj and cljs? I think i tried it in both repls and when foo was undefined, an error only occurred on the second line for both

I sent a related question on #cljs-dev with an example that does actually differ in implementation

ClojureScript 1.11.60
cljs.user=> (def ^a x [])
#'cljs.user/x
cljs.user=> (:tag (meta #'x))
a

Clojure 1.11.1
user=> (def ^a x [])
Syntax error compiling at (REPL:1:1).
Unable to resolve symbol: a in this context

Oh dang

Thanks that's a discrepancy

I guess that's due to the fact that vars in CLJS don't exist in the same way CLJ vars do. When you compile just (def ^a x 1) in CLJS, you won't even get that :tag a in the resulting JS. It simply won't be present at all. But if you also use #'x somewhere, that metadata will be there. But it will be - right where you used #' and not def. Of course, that metadata could include a instead of 'a, but perhaps it's done this way to not take the run time too far from the compile time since the value of a cannot be known at compile time.

Right (from https://clojurescript.org/about/differences#_special_forms): > Vars are not reified at runtime. When the compiler encounters the var special form it emits a Var instance reflecting compile time metadata. (This satisfies many common static use cases.)

metadata on vars is not evaluated and only stored in the analyzer data on the compiler side as EDN

only exception is :test which is actually handled be the compiler and evaluated

(for cljs.test purposes)

metadata on maps and stuff is actually evaluated becomes it becomes actual metadata on the thing in the runtime

finally caught up on this. this makes sense, thanks yall 👍

they share the same runtime so the line between a js value and cljs value is fuzzy. I'm sure you could draw the line somewhere, but without knowing the context, it's difficult to offer a suggestion for how to draw the line.

you can try filtering using these: object? http://cljs.github.io/api/cljs.core/objectQMARK array? http://cljs.github.io/api/cljs.core/arrayQMARK

(filter (some-fn object? array?) ...)

> so the line between a js value and cljs value is fuzzy yes I was wondering if anyone has devised somewhat reliable test and if it’s possible at all the particular case I was looking at was that of a goog.events.BrowserEvent which fails object? , but there might be others

BrowserEventitself is a function, which we can certainly test.

=> (js-fn? BrowserEvent)
true

=> (let [event (BrowserEvent. (js/Event. "foo"))]
     (instance? BrowserEvent event))
true

=> (defn clj? [x]
     (boolean (re-find #"\bthis.cljs\$lang" (.toString (type x)))))
nil

=> (clj? {})
true

=> (clj? #js{})
false

=> (clj? (BrowserEvent. (js/Event. "foo")))
false

There is really no useful line when it comes to functions. They all report the same type info. (Again, probably some edge case here I am oblivious to.)

=> (deftype Foo [])

=> (= (type (fn []))
      (type (.-stringify js/JSON))
      (type Foo)   ;; Foo is a constructor, aka function.
      (type BrowserEvent))   ;; Same for BrowserEvent.
      (type map)
true

(.toString (type (fn [])))
"function Function() { [native code] }"

=> (defn clj? [x]
     (boolean (re-find #"\bthis.cljs\$lang" (.toString (type x)))))
nil 

=> (let [coll {:fn (fn foo [] :bar)
                :event (BrowserEvent. (js/Event. "foo"))
                :coll [1 2 3]}]
      (into {} (filter
                (comp #(or (clj? %) (js-fn? %)) val)
                coll)))
{:fn #object[my$namespace$foo],
 :coll [1 2 3]}

> There is really no useful line when it comes to functions Yes functions is where I gave up 🙂 > For a general case, this little hack seems to get the job done Ha! that is a great little hack indeed! Thanks writing this up, very helpful 🙏