This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-12-16
Channels
- # adventofcode (36)
- # announcements (30)
- # babashka (1)
- # beginners (161)
- # boot-dev (2)
- # bristol-clojurians (3)
- # clj-kondo (10)
- # clojure (125)
- # clojure-europe (10)
- # clojure-italy (4)
- # clojure-nl (7)
- # clojure-spec (1)
- # clojure-uk (26)
- # clojuredesign-podcast (3)
- # clojurescript (13)
- # core-async (5)
- # cryogen (3)
- # cursive (134)
- # data-science (8)
- # datascript (3)
- # datomic (32)
- # fulcro (24)
- # graalvm (2)
- # joker (5)
- # leiningen (5)
- # malli (18)
- # off-topic (14)
- # pathom (4)
- # re-frame (3)
- # reagent (11)
- # remote-jobs (3)
- # rewrite-clj (8)
- # shadow-cljs (47)
- # spacemacs (3)
- # sql (12)
- # vim (6)
I’m migrating my legacy cljsbuild app (for Cursive licensing) over to shadow. For the web part, I compile separate JS for separate pages, i.e. I have pages for buy, renew, quote etc. They share some code but currently I’m compiling them into separate JS. They all use the same output dir. I thought that in Shadow I’d be able to use modules within a single build for this, but when I try to configure this I get the error: “two modules without deps, please specify which one is the default”. I’m not sure what that means - should I be using separate builds for this?
Are you using :depends-on
@cfleming?
E.g.
{...
:output-dir "public/js"
:modules
{:shared
{:entries [my.app.common]}
:home
{:entries [my.app.home]
:depends-on #{:shared}}
:login
{:entries [my.app.login]
:depends-on #{:shared}}
:protected
{:entries [my.app.protected]
:depends-on #{:shared}}
No, but in this case none of my modules depend on one another. They’re essentially independent apps.
Modules are used for dynamic load in one app, different apps should have their own build. localhost:9630 is the default web console of shadow-cljs, you can use it to start/stop your builds.
so as @U0G75S29H showed you need to declare one :shared
module that all others depend on. you can use :entries []
So when I deploy a production build, will that load two JS files for each page? The shared and then the page-specific?
So this is what I ended up with:
:modules {:shared {:entries []}
:pay {:init-fn site.pay/init!
:depends-on #{:shared}}
:quote {:init-fn site.quote/init!
:depends-on #{:shared}}
:buy {:init-fn site.buy/init!
:depends-on #{:shared}}
:renew {:init-fn site.renew/init!
:depends-on #{:shared}}
However when I compile, I get the following:
[:site] Build failure:
Module Entry "site.buy" was moved out of module ":buy".
It was moved to ":shared" and used by #{:buy :quote}.
this means that the site.buy
ns was used somewhere in the :quote
module. likely a direct (:require [site.quote ...])
It’s amazing how much shadow has removed the incidental complexity in my project, it’s very nice indeed.
If I make my quote module depend on buy and shared, then I guess I need to load both in my HTML? i.e. I need shared.js
, buy.js
and quote.js
in quote.html
? Or is the shared code all moved out to shared.js
?
I remember seeing in the doc that shared code is moved to the leaves as much as possible, is Shadow smart enough to see that shared is common to both buy and quote, and to put the code required by both there?
no you need to load them all. the goal is to move code as close to the "edges" as possible. the goal is to keep shared as small as possible
Is the order of loading the modules in the HTML important? I know I have to load shared before quote, but is there a good way to know that I need (presumably) buy after shared but before quote?
yes order is important. order is logical. all depends-on must be loaded before and that applies to all moduels being loaded
If I understand the documentation correctly, if I have a :node-script
build and I watch
it, then hot code reloading should just work - is that correct? Is something logged somewhere when code is reloaded in that case?
@cfleming did you specify the lifecycle hooks? either (defn ^:dev/after-load do-something-after-reload [] ...)
?
A simple question about the syntax this hook (or hook in generally), this is exactly the same, right ?
(defn ^:dev/after-load...
vs (defn {:dev/after-load true}...
Haha Ok thx 🙂
in node hot-reload is often tricky because so much state is kept in some callbacks somewhere
Yeah, in this case it’s a node script running a web server and a local dynamo - I guess I’ll have to shut all that down, reload and then restart them.
you just might be handing off a reference to some function that can't be hot reloaded