Fork me on GitHub

Had a pretty big headscratcher when experimenting with multiple web workers + shadow-cljs. Because adding a web-worker to the main app build ended up using some JS that's incompatible with web-workers (using window or such). I had to add an extra build and run it in parallel, that breaks hot-reloading but still works. However when I got to write and load a third worker things started getting weird. The main worker namespace kept on getting re-evaluated, even though the single namespace that requires the main worker was not, causing the workers that it loaded to keep spawning endlessly. I ended up fixing it by not using :worker in the :modules of the extra worker builds, they need to be unique over multiple builds I guess?


@bbss why did you not isolate the code using window and such so it doesn't get loaded by the worker?


loading 2 different development builds in the same page is gonna be problematic yes


hmm I hadn't really looked into the option, I guess starting my main build loads fulcro which was what broke it. Not sure how to isolate that.


{:shared {:entries []}
 {:entries []
  :depends-on #{:shared}}
  :depends-on #{:web-shared}}
 {:entries []
  :depends-on #{:shared}}
 {:init-fn your.worker1/init
  :web-worker true
  :depends-on #{:worker-shared}}
 {:init-fn your.worker2/init
  :web-worker true
  :depends-on #{:worker-shared}}}


having empty :entries allows them to "catch" dependencies to they don't go further up the graph


okay, I'll give that a shot!


so your app would would shared,web-shared,web1 in the page


I actually got something in the UI that should make it easier to figure out which code ends up where


still working on it though. lots of stuff left to do.


cool, yeah this would have helped. I had some assumptions but mostly it was hard to figure out what was going wrong 😅


but you should be able to "move" code around so that the worker doesn't load the DOM related code


I had tried some things but didn't consider an empty entries. I'll let you know if I figure it out.


they don't have to be empty. you can also force certain dependencies which might make sense too

👍 4

Super stoked you are going to have a go at doing something similar to Gatsby @thheller I've been chipping away at it with Shadow Jam but I'm sure what you can come up with would be way better than what I can put together 🙂 Plus you can make the whole experience much more integrated.


At the moment I am doing a couple of websites that have so little JS interaction I can't justify shipping the React runtime. So I'm just using Rum in Clj to generate the static html and Shadow Cljs to create the JS scripts that actually do work on the page. It's been so easy to do with Shadow-cljs

Logan Powell17:09:32

Sorry for the potentially stupid question, but if I get a Socket closed exception when I terminate my shadow-cljs clj-repl (node repl) after working with some core.async I/O, is it due to me not close!ing a chan?

Logan Powell17:09:02

I only get this exception thrown after ending my REPL session and only when I'm working with core.async


@loganpowell no idea. don't worry about it if you are ending the repl session anyways. it might be something async trying to write to the socket you just closed

Logan Powell19:09:25

@thheller thank you for the piece of mind. Moving on...


is that the full error you get or does it have a stacktrace?


hmm weird. why is nrepl in there at all? did you open a second connection in an editor or so?


but yeah you are quitting the actual server not just the REPL


so any open connection will be forcefully terminated .. leading to such exception if something was writing to it or trying to write to it


there might be a race condition where something tries to notify something else. I'll see if I can just mute exceptions during shutdown

Logan Powell19:09:06

no worries. It's not having an impact on me except for the shutdown exception.

Logan Powell19:09:03

I'm using a remote REPL, yes. I was having issues with the terminal in IDEA