Does anyone know if it is possible to slurp an externs.js file for a cljsjs package?

I need to access externs.js file (for a cljsjs package) from Clojure. What’s the best way of doing that

Have any of the ideas from atomic-layout been ported to clojure? Or does anyone have any thought or opinions on it? I'm just starting to look into it and i'm not sure i get the picture just yet.

@ag If you know the name of the file in the JAR, you could use io/resource to access it, like this:

$ clj -Sdeps '{:deps {cljsjs/react {:mvn/version "16.9.0-0"}}}'
Clojure 1.10.1
user=> (require '[ :as io])
nil
user=> (slurp (io/resource "cljsjs/react/common/react.ext.js"))

You could even get at the name of the externs file like this

user=> (:externs (read-string (slurp (io/resource "deps.cljs"))))
["cljsjs/react/common/react.ext.js"]

Oh, sorry, just noticed the crosspost on #clojure

Are the performance characteristics for :extend-via-metadata protocols different than for regular protocols?

yes

if true, then you have 3 options - direct invocation, always tried first, no difference in perf

metadata extension second, external extension third

b/c #2 is checked, #3 is slower

or rather, all the answers above are for Clojure. I assume similar for cljs, but could be wrong.

Thanks! Im not sure I fully understand what you’re referring to with “external extension” though? extend-type?

yeah

How about WASM ? Are we ready to it ? Are there any implementation ?

not sure how much upside there would be at this point

a large runtime, including gc, would be required

also, clojure being hosted, there’s not really anything on the host side in wasm

Ok, something super weird is going on with some data I have. I'm in a CLJS REPL:

x
=>
[{[:metric/id #uuid"0a9640da-13a0-49b6-9e82-87b38ac2619f"] [{(:metric/dashboard-series
                                                              {:window [#inst"2019-09-06T16:20:32.277-00:00"
                                                                        #inst"2019-09-06T19:20:32.277-00:00"]}) [:dashboard-series/name
                                                                                                                 :dashboard-series/points]}]}]
y
=>
[{[:metric/id #uuid"0a9640da-13a0-49b6-9e82-87b38ac2619f"] [{(:metric/dashboard-series
                                                              {:window [#inst"2019-09-06T16:20:32.277Z"
                                                                        #inst"2019-09-06T19:20:32.277Z"]}) [:dashboard-series/name
                                                                                                            :dashboard-series/points]}]}]
(= x y)
=> false

(= (get (first x) [:metric/id #uuid"0a9640da-13a0-49b6-9e82-87b38ac2619f"])
   (get (first y) [:metric/id #uuid"0a9640da-13a0-49b6-9e82-87b38ac2619f"]))
=> false

@kenny it is the dates ie. #inst

I don't think so. This arose because I couldn't write some transit:

(cognitect.transit/write
  (cognitect.transit/writer :json)
  y)
Error: Cannot write 

That error goes away when I get rid of the list.

hmm you are right. dates seem to be fine

x was defined like this:

(def x '[{[:metric/id #uuid"0a9640da-13a0-49b6-9e82-87b38ac2619f"] [{(:metric/dashboard-series
                                                                       {:window [#inst"2019-09-06T16:20:32.277Z"
                                                                                 #inst"2019-09-06T19:20:32.277Z"]}) [:dashboard-series/name
                                                                                                                     :dashboard-series/points]}]}])

If I dig way into that structure, it is actually a List

(type (first (keys (first (get (first y) [:metric/id #uuid"0a9640da-13a0-49b6-9e82-87b38ac2619f"])))))
=> cljs.core/List

y also came from a macro, in a way.

But the macro isn't doing anything strange. It's just pulling the value out and putting it in another place. Either way, the two values look fine.

Well that was fun... Turns out it was the dates! The dates were generated from cljs-time haha

Not sure that I agree with cljs-time on writing a cljs-time object just like a #inst