This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (13)
- # aleph (5)
- # announcements (8)
- # beginners (87)
- # calva (9)
- # cider (102)
- # cljs-dev (71)
- # cljsrn (2)
- # clojure (198)
- # clojure-dev (28)
- # clojure-europe (3)
- # clojure-italy (27)
- # clojure-nl (3)
- # clojure-spec (1)
- # clojure-uk (43)
- # clojurescript (121)
- # component (11)
- # cursive (20)
- # data-science (13)
- # datascript (2)
- # datomic (102)
- # dirac (4)
- # duct (5)
- # emacs (14)
- # figwheel-main (7)
- # fulcro (37)
- # hoplon (11)
- # jackdaw (3)
- # jobs (2)
- # leiningen (16)
- # nrepl (2)
- # off-topic (51)
- # pathom (34)
- # pedestal (12)
- # perun (10)
- # portkey (1)
- # re-frame (6)
- # reitit (1)
- # shadow-cljs (21)
- # spacemacs (8)
- # tools-deps (2)
- # vim (2)
small update on the new closure-library. it completely breaks
cljs.loader (and the shadow-cljs variant
shadow.loader). no longer accepts pure json data for config but must instead use some TrustedResourceUrl instances.
setModuleUris is gone and replaced by
a bunch of other smaller issues as well but those are mostly related to shadow-cljs not using the built-in "debug" loader. should be fine in CLJS as @mfikes mentioned.
Yeah, a few method names where changed goog.module. I was thinking about chasing down changes if nobody else is already tackling it.
k, I'll look into it over the weekend. Working on some code-split stuff in-house and I'd like to iron out the kinks.
Maybe we currently have insufficient tests around
cljs.loader? (Wondering if Canary would catch Google Closure breaking it.)
I'd love to learn more about how to add tests to the suite. Is that already part of any contrib guide?
I think there are at least guides telling you how to run all of the various tests (which gives an indirect hint of where they are located). But just ask and I'd be happy to help
ah k. So if any basic method name or API changes are necessary, those'd be helpful to chase down?
Ahh, yeah, maybe
cljs.loader's code would cause warnings to be emitted at compile time instead of failing at runtime...
A smaller, more concrete example:
1) Be inferred as returning a string
2) Cause a compilation warning if, for some odd reason
gstring/trim dissappeared, required 2 arguments, etc.
On the subject of cljs.loader... I've found the need for using
loaded assets. I've also heard others (2 other users besides myself) asking about
alias in cljs in #clojurescript recently. If I had
alias, I could convert a lot of my existing codebases to modular format with minimal code changes (just by annotating some hiccup forms with reader tags). So I just wanted throw that on y'all's mental model and let it percolate, in case opportunities avail themselves.
maybe he means this? https://github.com/clojure/spec.alpha/blob/master/src/main/clojure/clojure/spec/alpha.clj#L15
Sorry, so, perhaps I'm not thinking about this right... but I'd like to be able to do
(cljs.loader/load :blah (fn  (resolve 'short-alias/some-var))) rather than
... (resolve 'my.really.really.long.name-space/some-var)
I don't think so, but how could that possible know which module's namespace is providing the var?
It allows one to use the same aliased var at the call-site, without having to change any code, under some conditions. (if the lazy version of your codebase uses the same convention between ns aliases and a top level call to
Def a convenience feature... But not possible from user-land via macros without support from core.
reader conditional unsplicing is not allowed at the top level
that's what I'm saying isn't allowed
there is no context to splice into at the top level
I have a reader tag that transforms ns forms and I was hoping to drop some extra defs after the ns declaration. I guess a second call to something after the ns form is the only way
To simulate alias modules, I can just have
lazy-alias def (in the current namespace) a map of aliases to namespaces and then just do the lookup when later transformations detect a qualified symbol.
many people have tried to build this. it usually doesn't end well.
usually if you need splicing at the top level, then a
do wrapper will work, but
ns forms are particularly problematic due to the "Gildardi scenario"
at least in Clojure world, don't enough details about cljs
I think ns in a
do might have worked in testing... But yeah I'm not sure if I'll trust it long term, given expectations
Never heard of that Gilardi scenario, but technomancy wrote a blog about it: https://technomancy.us/143
it’s also a common problem in boot files: https://github.com/boot-clj/boot/wiki/Run-time-requires-(within-task-definitions)
Hmm... looks like my usage wouldn't be hit by Gillardi, because AFAICT I'm not calling references to the foreign vars directly.