Assuming you already have a worker set up:

(def worker-data (atom nil))

(set! the-worker -onmessage #(reset! worker-data (.-data ^js %)))

you probably want to serialize stuff back and forth. doubt you are just gonna send js data

I looked at this more the ideal solution is transferring ownership of an ArrayBuffer if I go in this direction. My thoughts was actually if someone had wrapped SharedArrayBuffer with IWatachable or something.

IMHO that is nonsense unless you actually just sharing binary data. CLJS datastructures are not binary data, so either way you are going to serialize them. if you serialize them you might as well just transfer a string, eg. edn or transit.

https://clojurescript.org/reference/google-closure-library#import-an-enum

Hmm, that hasn't worked...

Says it can't be found

FWIW JS doesn't have enums. its just a javascript object, so the same interop rules like any other JS object apply

The required namespace "goog.crypt.base64.Alphabet" is not available, it was required by

#?(:cljs (:import [goog.crypt.base64 Alphabet]))

(:require [goog.crypt.base64 :as b64]) b64/Alphabet.WEBSAFE

The error is because the enum isn't defined in its own file.

@U05224H0W I was worried that might not work across compilation styles 😄

ah, OK 😂

goog is inconsistent, yeah. :) Gotta be somewhat creative.

imho :import makes little sense in CLJS. :require does everything you need

:import was added a long time ago to solve a specific problem - when the namespace is a constructor

but since we added using :as aliases as "vars" this became redundant no? ["some.thing" :as x] (x.) works now, same for closure lib

all stuff that came way later - there’s too little value in changing this kinds of really old decisions

pretty sure treating aliases as invokeable things also came way later

I'm not saying to change it at all. just saying that :require now covers everything :import previously did, so it is no longer "required" to use

right I just mean :import does exist for a good reason even if it is historical

and this largely about aligning Clojure / ClojureScript

of course not meaning to make a pointless argument

it might have a been a bit clearer w/ “:require now does everything you need”

Is it worth updating the documentation around how to use the closure library if :require can now do it in place of :import?

agree with dominic. there are cases I have used :import where :require is sufficient. itd be nice to reflect "modern clojurescript" in official documentation.

note that there is technically nothing wrong with :import and it is fine to use. the only problem is that the closure library is somewhat inconsistent in how things are structured. so some things are actual "namespaces" while others are just "vars" (as in property of the namespace) or even properties of other vars. so while :import might work for some it won't for others. :require is a bit more forgiving that way, but still not immune either.