This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-06-13
Channels
- # babashka (5)
- # beginners (52)
- # biff (11)
- # brompton (5)
- # calva (2)
- # cider (7)
- # clojure (80)
- # clojure-europe (3)
- # clojure-finland (1)
- # clojure-nl (3)
- # clojure-norway (1)
- # clojure-uk (3)
- # clojurescript (15)
- # conjure (4)
- # core-async (9)
- # cursive (3)
- # datahike (38)
- # datascript (1)
- # datomic (7)
- # duct (9)
- # emacs (4)
- # fulcro (11)
- # graalvm (21)
- # honeysql (5)
- # lambdaisland (1)
- # leiningen (1)
- # news-and-articles (1)
- # off-topic (8)
- # react (42)
- # reagent (6)
- # reitit (11)
- # shadow-cljs (62)
- # specter (1)
- # spire (2)
- # sql (1)
- # tools-deps (12)
- # vim (5)
Hi, I’m looking for a quick hint in case this sounds familiar: My reloading works in the sense that terminal states “Build completed. (415 files, 2 compiled, 0 warnings, 0.66s)“, HUD in browser informs that reload occurred, but nothing actually changed (what I did was adding a Reagent [:h1 “foo”] element to page). Browser console stated “shadow-cljs: reloading code but no :after-load hooks are configured!“, but in general there’s nothing I want to do after load. What am I missing here? :thinking_face: Background: I’m moving a somewhat large project to shadow-cljs. It’s a “re-frame project” based on a Luminus template from 2017, and it has been using lein-figwheel up until now. I just went for the transition and it was a lot smoother than I feared, and it even pointed out quite a few bug along the way. Any ideas?
Code is served by the Immutant based web server created by the mentioned Luminus template. I see that when I change the config in shadow-cljs.edn, my Reagent/Hiccup are propagated to browser.
@mokr you need to actually trigger the re-render yourself. thats what the hooks are for. see https://code.thheller.com/blog/shadow-cljs/2019/08/25/hot-reload-in-clojurescript.html
Thanks, @thheller this is the kind of pointer I was looking for. Now I need to do some more reading.
I’m actually in the process of reading the complete docs, and was reading that chapter just now. I think the main problem for me is that I have “outsourced” quite a bit of the setup/plumbing to Luminus. That has been serving me very well, but when I now sit down and want to do shadow-cljs from scratch I miss some details, I guess. Anyway, thanks again.
figwheel works the exact same. you tell it what it should call when its done loading and it does.
just look for :on-jsload
in your config. you maybe never noticed it when your template generated it 😛
I think that is always a benefit, but as a on-man-show I had to prioritise other tasks. I believe that was the right thing to do at the time, but it does bother me to not understand better why it works.
BTW: Is shadow-cljs working well in Docker? Issues with reload time for lein-figwheel in docker is actually what pushed my to finally start on the transition. Docker as a DEV environment, that it.
Ok, I guess I will find out soon enough. It’s not a dealbreaker, at all, but it would be nice to be able to run dev in the same environment as production.
It would just feel nice to be able to fire up a working dev environment based on a docker-compose stack, and run the production code in a kind of pre-prod sense locally.
I know that file-watching used to be a problem and that the default didn't work. so you had to use the polling watcher instead which is quite a bit slower.
no clue if that is still current though. was like 2 years ago the last time someone asked
That is exactly what I was spending my time on yesterday. Still an issue on MacOS as far as I can see.
Nice, thanks. But what kind of user experience should I expect from this? What’s the drawback?
In a sense I would say you are missing out on something quite useful, but I don’t know what you are doing apart from shadow-cljs 😀
Oh, for me it was quite the opposite. At least I did see something that would fit in my “toolbox” and solve real problems at work.
but shadow-cljs is not part of that stack so I have no interest in putting it into docker 😛
treat the output just like your production env. static files served by some webserver. thats great.
The local dev thing was driven mostly by frustration that “lein new luminus myproject +re-frame ….” stopped working locally on my Mac. For shadow-cljs dev the great thing would be that everything is wrapped up in something that works. No local setup apart from Docker.
As it looks right now, it won’t be my go to solution either. CPU usage and delays will not be as good as I would want. But, I think I will still try it out jut for fun. 😊
While we are at it; What about the Clojure side of things? I’m looking into deps.edn, but I haven’t decided what to do about handling dependencies, running the Clojure based backend in dev and generating the executable jar used in prod. Any tips?
And just to confirm; Adding ^:dev/after-load to the function called by figwheel’s :on-jsload solved my initial issue. Thanks for taking the time @thheller, I really appreciate it! 😊 I’m confident that I will be in a way better position when this transition is done. My previous experience with shadow-cljs + D3.js code in plain JS was really pleasant, so I can probably reduce the complexity of the codebase going forward (D3 code is currently cljs)
I am building a chrome extension with shadow, and it for some reason adds one of the background scripts into the content_scripts entry in manifest.json, and I can't understand why. That script's ns appears in requires only in two other namespaces, neither of which are content scripts: one is the main background ns, the other is the options page for the extension, neither of them is require'd in any other namespace and they don't appear in the content_scripts list in manifset.json. mount/start
for some reason picks up on the states defined in that background namespace and tries to start them when starting the content script. Is there a way to determine why it is being added?
well its your ns :require
controlling all of this but no there is easy visualization or so for this
been meaning to replace the old variant I had for this once but didn't get to it yet
It is also the fourth entry from the bottom of the content_scripts list. I assume the files there are in topological order there (?), and the ones after it are shadow.module.bg-shared.append.js
, ampie.content_script.content.js
(my content script ns) and shadow.module.content-script.append.js
, that background script is referenced in neither of them.
note that ALL dependencies count when determining where something ends up. so you content scripts might not require something from the background directly
I'll double check, but the files that require that ns are themselves not included in content_scripts list.
I removed the reference to it from the ns that is compiled as :chrome/single-file
and that entry disappeared from the content_scripts.
So all the dependencies of single-file targets are added to content_scripts?
What do you mean by sharing as much code as possible?
So the thing seems to be: ns in question is required in a background script and in a single-file script. If I remove the require from either one of those places, it disappears from content_scripts list, otherwise it is added there (unnecessarily, since it isn't required in any content scripts even indirectly). I created a new ns and required it in those two namespaces, the same behaviour repeated.
So shadow is trying to put the namespaces that appear as dependencies several times into the content_scripts list?
Ok, I'll try to make an example later.