Okay, here's an early crack at it: https://github.com/johnmn3/in.mesh

in https://cljs.github.io/api/syntax/dot says (js/console.log "HELLO") and (.log js/console "HELLO") are equivalent. Can this also be applied to module imported with shadow? I have ["slate-react" :refer (ReactEditor Slate Editable withReact)] under my namespace, and: • (ReactEditor.focus editor) didn't work. • (.focus ReactEditor editor) works. Is this the difference I need to notice between normal cljs and shadow?

@s0930161 my own personal rule for this is to only use the . when using namespace qualified symbols. which also happens to play nice with my other rule of barely ever :refer. so I would to ["slate-react" :as sr] then (sr/ReactEditor.focus)

or you can also so ["slate-react$ReactEditor" :as sre] and (sre/focus)

no intended difference between cljs and shadow in this. should all behave the same.

@john nothing stops you from doing a separate build for the worker in shadow-cljs. the final result is larger than it needs to be so I don't recommend it but you can. as for the REPL the editors just don't support picking the runtime. you can REPL into the workers just fine. has nothing to do with modules though. (shadow/repl-runtimes :the-build) then (shadow/repl :the-build {:runtime-id 123}) using the :client-id listed in the previous command. (unfortunate renaming incident left in those thats why the names differ)

Okay, that's pretty awesome

I'm trying to imagine what it would look like to reduce friction as much as possible wrt letting users spawn webworkers, without having to necessarily deal with build configs. But, in the default quickstart scenarios that may be easy, but when a user is preferring to use multiple build ids and/or multiple modules, then we don't know where to target that webworker spawn fn without more input from the user, right? Two questions: 1. Would it be possible, from within the lib, to issue a request to spawn a webworker build for an existing build, if one doesn't already exist? (say, in the default quickstart scenario) So that in simple cases users don't have to change build configs? and 2. For more complex scenarios, would it be possible to let user's pass build id and/or module id in on the spawn fn to allow them to generate a new build or module (not yet existing in the build config) based on whatever is passed in?

Like, does shadow expose a programmatic API such that a lib that one brings in could optionally extend their current build configuration? And how hairy would that be?

@john I think you could do that with a build hook - https://shadow-cljs.github.io/docs/UsersGuide.html#build-hooks

Hmm, that requires changing one's build config though... My feeling is that, in the default situation, users shouldn't have to make augmentations to their build config in order to use webworkers in clojurescript. I feel like spawning workers should be a supported use case after completing any of the quick start directions for raw cljs, shadow or figwheel.

Having a lib that provides it's own worker script with importScripts that pulls down things in the correct way would be fine, but IDK how much other stuff shadow and figwheel are doing throughout the rest of the build to accommodate workers, so I wouldn't want to break the build tool's expectations

Option 1: depend on the build tool's worker-import-script for pulling down dependencies, potentially requiring the user to make build config changes, Option 2: provide a default worker-import-script that tries to do the right thing for all the different build tools, independent from their own configs

If worker-import-script is mostly just a small thing, and most of the build is the same, why don't we just always ship a worker-import-script for every build? As long as it can reuse all the existing code in the non-worker build artifact, it's just an extra KB or two

And if the user wants to learn how to go through adding more build ids or modules to their build config, then they can easily just pass the same IDs to their spawn fn, like (spawn {:build-id ..., or module id. Currently, there's really no way to ship libs that provide web worker capabilities without forcing their users to learn advanced build ceremony, which is different for every build tool

In an ideal world, CLJS could have some worker fn in core, and the different build tools could fulfill some contract that makes it work. Few other languages impose this much ceremony to achieve programmatically spawning parallelism

But short of that, maybe we can provide that via a lib, so that's what I'm exploring now

Hmm, I see theres https://cljdoc.org/d/thheller/shadow-cljs/2.4.2/api/shadow.cljs.devtools.api

I see I can get shadow/active-builds and then shadow/get-build-config for the active builds. But can I then update those build configs at runtime?

I'd potentially want to duplicate existing modules with sister worker module configs, just adding :web-worker true, allowing you to connect to them via a worker optionally

With maybe a shared module between them, so the worker is just adding the shim code

Or maybe I can just have the worker :depend on the non-worker one