not sure exactly what you're trying to do, but Chrome let's you profile your app and save it to a json file. You could then post process it that with a sourcemap.

there are a few other options, but it's not clear what your end goal is.

(map #(alter-var-root %
                      (fn [f]
                        (fn [& args]
                          (println "before")
                          (apply f args)
                          (println "after"))))
     (vals (ns-interns ')))

I don't see how to get what I want out of tools.trace.

If that even works on cljs, I haven't tried it.

I'm actually interested in generate a trace and then importing it into chrome to browse it.

right, but why do you want the trace?

the profiler does a decent job of tracing, but it looks like it's a sampling profiler.

The trace that chrome gives me isn't helpful. I see mostly anonymous functions and stuff unrelated to what I'm trying to debug in my app. You're suggesting that if I postprocess it with a source map then maybe I can get what I want? I haven't considered that.

if there's a sourcemap, I think google chrome might do it for you

I'm still interested in generating a trace of my functions. I'm sorry if my first example was unclear or confusing. Hopefully the pseudocode example makes it clear what I'm trying to do.

I know Chrome does use sourcemaps with debugger

If you need full instrumentation, you can check out how cljs.spec does it, https://github.com/clojure/clojurescript/blob/r1.10.914/src/main/cljs/cljs/spec/test/alpha.cljc#L109-L167

looks pretty hairy

That's a good point, thanks.

With shadow you declare js deps in a package.json. from there, check the shadow docs to match how the code is imported in js and against the shadow/cljs equivalent.

Thanks! For future references: https://shadow-cljs.github.io/docs/UsersGuide.html#classpath-js

JS byte arrays can be accessed with aset/`aget` just like byte arrays in Clojure

I should've been more clear - by their API I meant the fields/methods accessible via interop. Java arrays should have things that all Java objects have. Same for JS objects, but those methods are different, plus UInt8Array has a whole bunch of other methods. It might or might not matter - impossible to say without the context.

No I actually want to export a map from a file as default and then import it in another file.

I have come to know that I can ^:export to export but how to do it as default

So the file with the map is a CLJS file and the file that needs that map is a JS file?

nope both of the files are cljs files? please tell me if there is a workaround too

There's no workaround - your mindset is simply wrong about the problem. Exporting as default is a JS construct, it doesn't exist in CLJS. If you have something like (def my-map {...}) in namespace a and you need that map in namespace b then all you have to do is add [a :refer [my-map]] to the :require list of the (ns ...) form in the namespace b. To avoid polluting namespace b with all the new names that you require, you can require namespaces with aliases or with only their names. So if you require [some.long.namespace.name], then you can use . And if you require [some.long.namespace.name :as n], then you can use n/my-map.

oh thank you very much, I am actually translating a react app and became a perfectionist in translating each and every construct.

That's alright, but I would retarget that perfectionism. :) From "it must be 100% as the original" to "it must behave in the same exact manner but be written the CLJS way". Otherwise, you'll be writing JS in CLJS, and that's a painful road.

fetch is a more recent API. Pretty sure that's the reason.

found https://github.com/lambdaisland/fetch 🙂