How do you actually include assets file from a cljsjs repo using leiningen?

I'm trying to use cljs.js in a fairly naive way to have a bootstrapped repl, and what I'm seeing is that after I do a require, even though it appears everything succeeded, it still doesn't "know about" the loaded namespace. I can actually access vars and values, bu I get a warning in the JS console about using an "undeclared Var". Does this sound like any kind of specific mistake I'm making with cljs.js to anyone ?

Ah, it is internally throwing due to it already being provided.

I see this: https://github.com/clojure/clojurescript/wiki/Custom-REPLs#eliminating-loaded-libs-tracking

It's surprising how challenging it has been to figure out how to build a simple embedded repl. Lots of stumbling blocks.

@pmooser Interesting. I’ve actually not looked at cljs.core/*loaded-libs* behavior in self-hosted, focusing mostly on cljs.js/*loaded*.

It's really not terribly clear (at least to me) exactly what the minimal required setup is to get a repl that doesn't break like this in subtle ways. I don't even receive the exception when the underlying closure library doesn't load the library - I only saw it because I had a breakpoint.

@mfikes I've tried to look at cljs.js/loaded but I'm often seeing it not update after a require that 'appears' (to me) to be successful, but I suspect it's all due to this same issue, at least for now.

@pmooser Are you retaining the result of (cljs.js/empty-state) in a var and reusing it between evals?

Yes, I have a defonce in my namespace.

The node repl looks like it may be super informative for me.

@pmooser Ahh, yeah, I wrote this based on that about 3 years ago https://github.com/mfikes/planck/blob/master/planck-c/engine.c#L285

Ah, sadly, it complains that CLOSURE_IMPORT_SCRIPT is undefined. That's what I get for traipsing around in code I don't understand at all. 😞

I forgot about *loaded-libs* completely

Ah interesting, yah!

Keep going! I think it took me 2 weeks to finally get Ambly working, and I think I gave up 3 times during the process. 🙂

Do you know offhand what causes CLOSURE_IMPORT_SCRIPT to get defined ?

It has been so long, archeology of the code is all I have: https://github.com/mfikes/planck/blob/master/planck-c/engine.c#L242

Heh, well thank you for the references and the encouragement! I am sure this is the right direction.

That is sort of perfect actually, and I found a similar snippet.

There have been more humans to have walked on the moon than have created REPLs from cljs.js, so…

Well, it gets to ALMOST working immediately - like it's almost SO easy.

It actually works really well until I start requiring things.

say I have a function that returns a native JS Promise (`#object[Promise [object Promise]]`). I want this function still returning a promise, but I want the value that this promise resolves to, to be cljs-friendly (js->clj, keywordized keys etc). Can this be done?

@fbielejec Add a .then callback to the promise, converting all you want to do in there?

as in return a new Promise from the callback? That should do it.

Has anyone noticed in ClojureScript 1.10.x that cyclic dependencies aren't being detected?

I've just had one and it causes my build to run forever within figwheel.

@olical This was also an issue in 1.9 with parallel build, maybe in 1.10 the default is to build in parallel

@olical you can also try if https://github.com/clojure/clojurescript/commit/56c774be6227d51f4aa3a52571cb2640c7325db7 fixes it

Morning, excellent ClojureScripters; I’m trying to debug a weird, an I’m having trouble even building an intuition about where to look. Goes like this: when I build my CLJS with :optimizations :none, my CLJS bundle is trying to look for its extra js modules (i.e. base.js, cljs_deps.js) in a path that’s mutated depending on the route requested. So, if I request, say, /about, everything works fine; if I request /monkey/about, /monkey is now prepended to the asset path, and everything breaks.

What are the odds that someone else has seen this, or built this particular footgun for themselves before?

(My casual guess is that I have done something really clever, but I’m still deeply in the “what even” phase of trying to figure out what.)

@byrongibby Does your asset-path starts with a /?

@me1740 there isn’t any chance you meant that question for me, is there?

@gastove yes, sorry

No worries 🙂 I get the same behavior whether or not :asset-path starts with a /

I’m serving a CLJS single-page app from a CLJ server using http-kit; I have no idea if it’s possible some other thing is prepending bits to incoming requests.

The fact that it only works at the root of your paths makes me think it is an issue of relative URI in the asset-path. I would look at the paths of your <script> tags in the html when you visit /monkey/about. You will also have to recompile the ClojureScript once you change the asset-path.

Hrmm, lemme monkey with that a little more

Yeah that… does not seem to be changing anything.

With script tag: <script src="/js/compiled/voltron.js" type="text/javascript"></script> I still see requests coming in for {:* "/monkey/js/compiled/out/cljs_deps.js"}

This is perfectly dynamic, you understand. If I now try to hit /i/am/the/walrus, I see {:* "/i/am/the/walrus/js/compiled/out/cljs_deps.js"}

It's clearly not generating the right JavaScript paths. I would look at the build options you use until you can see the right paths being injected in your html file.

I am indeed doing that! I am just… at a loss… for what could possibly be going wrong.

My compiler options look like so:

:compiler {:main voltron.core
                  :asset-path "/js/compiled/out"
                  :output-to "resources/public/js/compiled/voltron.js"
                  :output-dir "resources/public/js/compiled/out"
                  :optimizations :none
                  :source-map true
                  :source-map-timestamp true
                  :preloads [devtools.preload]}}

What I don’t understand is why the CLJS compiler would have dynamic asset paths at all.

I encountered the same issue a few days ago. Putting an absolute path in :asset-path fixed it for me. I was calling the cljs.build.api/build function directly though. Is it possible that whatever compilation tool you're using is fiddling with this parameter? Unlikely but who knows... Otherwise I'm out of ideas, sorry.

Gads, I hope not. I’m using the lein cljsbuild plugin. Can go see if I’m using a current version.

Yeah, current enough.

…..okay…. so a thing that makes this make even less sense is that my compiled JS is using absolute paths:

if(typeof goog == "undefined") document.write('<script src="/js/compiled/out/goog/base.js"></script>');
document.write('<script src="/js/compiled/out/goog/deps.js"></script>');
document.write('<script src="/js/compiled/out/cljs_deps.js"></script>');

Neat.

Ah.

Caching

The problem was browser caching, that’s wonderful --

Setting an absolute path for :asset-path was the right answer all along.

“The real software development was the caches we cleared along the way.”

I'm trying to get how the cljs repl works exactly (and when/where things are done). So, would this be accurate?

+
       host        |           JVM
                   |
+---------------------------------------+
                   |
       read        |
        +          |
        |          |
        v          |
   expand tagged   |
   literals        |
        +          |
        |          |
        |          |
        +-----------------> macroexpand
                   |            +
                   |            |
                   |            v
                   |         analyze
                   |            +
                   |            |
                   |            v
                   |           emit
                   |            +
                   |            |
                   |            |
       eval <-------------------+
         |         |
         |         |
         v         |
       print       |
                   |
                   +

@kurt-o-sys everything is on JVM side, only eval is on the host

ok, thx! What still confuses me are the tagged literals: they are expanded - not sure if I should call it like that - by plain functions (data readers). So, that's also on the JVM. Are they the same as/similar to edn tagged elements? If I'm not mistaken, edn custom tag parsers must/can be implemented on the platform they are read?

hello everyone, what's the easiest way to to add twitter bootstrap to a reagent project?

@joelv I don’t think you need to do anything special. Just include the css and JS from a cdn using a script tag and start using it.

@dnolen the REPL is actually more like a 'read-compile-eval-print-loop'?

@kurt-o-sys basically everything is JVM

the only thing we use the client for is eval, and some bootstrapping stuff

(how to load files, etc.)

well it’s the same as Clojure from one perspective

eval is compile

but in our case we can’t eval in our process

or rather

it’s not always true

right - trying to warp muy wrap my head around it, I'm getting close 🙂. oh, eval=compile, but eval != macro-expansion?

it’s true in the case of Nashorn & Rhino for example

eval is probably anything after reading

doesn’t matter macroexpand, compilation etc.

the only big picture difference is that Clojure can load some byte code into the JVM, ClojureScript has to send source to a JS engine

so, all after reading is eval, so macroexpand is part of eval, right? And macroexpand is ran on the JVM (since that's clojure code, not clojurescript)?

well yes … but it’s ClojureScript too, the whole compiler can compile itself into JavaScript

ok, that makes sense (mostly). I just stick with eval is partly ran on the JVM (macro's) and partly on the host (code after macro-expand), not taking into account cljs-in-cljs.

your diagram is closer to the mark

the only thing that the host is going to run is stuff generated by emit

ok, thx! That'll do.

(and maybe I should rename 'eval' with 'execute' or so?)

I think in the REPLs it’s js-eval or something

and the higher level stuff is eval-cljs or evaluate-form

ok. simplified: eval = macro-expand + js-eval|eval-cljs|evaluate-form (or something)

eval/eval-cljs/evaluate-form = macroexpand + analyze + emit + js-eval

eval/eval-cljs/evaluate-form = JVM[macroexpand + analyze + emit] + JS[js-eval]

right!

thx! that clarifies it all.

@mfikes @dnolen You were looking for feedback on ClojureScript 1.10.145 (and the previous version). I think it is worth mentioning in the release notes that taking a val of something that didn't come from a map no longer works and causes an error. I had that bug in my code and it manifested itself after upgrading ClojureScript from 1.9.946.

(my code was taking a val of a two-valued vector)

I'm so glad I have client-side exception logging implemented (along with source map decoding on the server).

Right. (val [1 2]) is incorrect. (It will fail in Clojure as well)

It undoubtedly is, but it seems that ClojureScript 1.9.946 tolerated it, while newer versions do not. I'm not disputing the bugness, I just think it's worth mentioning.

@jrychter it’s questionable since I didn’t know that worked

And BTW, ClojureScript 1.10.145 works perfectly well for me in a largish app.

there’s lot of weird edge cases that are best not talked about IMO

@jrychter that’s good news

That may be true — ultimately it's up to you to decide. I'm just reporting.

Yeah, there is other incorrect code that ClojureScript 1.9.946 accepted. Another example is https://dev.clojure.org/jira/browse/CLJS-2476

And I'm quite happy with the new ClojureScript version, mostly because it includes a newer Closure Compiler, which implements the "@noinline" annotation. Thanks to this, I was able to nicely macroize Font Awesome icon paths and include SVG only for those icons that I actually use, in an efficient manner. Rather Awesome, if you ask me.

@jrychter Thank you! Incorporated your feedback https://github.com/mfikes/clojurescript-site/commit/6be0febccc732d2b01ae894161729caef4913f5a

@jrychter You mention macroize... I wonder if :closure-defines and DCE works in that case. (Mostly curious, no need to try; just thinking about the side-effecting macros making code no longer cache-friendly. This works in "project" code, but can cause an issue if it is put into a JAR.)

(Referring to the note near bottom of https://github.com/mfikes/clojurescript-site/blob/issue-183/content/news/2018-03-12-shared-aot-cache.adoc)

@mfikes Oh, there is only a single macro, which references vars defined with @noinline. So yes, only the vars that are actually referenced are included, and only once.