I have something that looks like this in advanced compilation (first is (js/console.log %) second is (js/console.log (pr-str %))

It is supposed to be a transit bigdecimal (I think). How do I get a bigdecimal representation out of this? Or, if not possible, how do I get just the value in ka reliably.

I know I can (aget obj "ka"), but I am not sure that is stable under advanced compilation.

@samedhi It should be the rep field, so (.-rep x)

How do you deal with the HTML5 history API? I have a search app (re-frame), and employ Accountant for history manipulation. You request a search, it goes and does it, and then sets the URL. Setting a URL, however, issues a dispatch to the search event. This is not an endless loop; it's short-circuited since the search event won't issue a search if nothing has changed. Still, I would like to avoid that second search. It's just useless. Is it possible with the history API to set a URL without dispatching it? Accountant itself doesn't offer this option as it turns out.

I think I found a regression between ClojureScript 1.10.439 and 1.10.520. the following code snippet (reduced as much as possible) compiles fine under 1.10.439, but throws an exception on 1.10.520 during compile:

(def ^:dynamic *remote* (when js/window
                          ""))

(cond
  *remote* (println *remote*))

if you have a dynamic binding that somehow touches a js/* object and that binding is referred on both sides in the cond, compilation fails with:

Failed to compile build figwheel-default-repl-build in 0.224 seconds.
java.lang.NullPointerException
        clojure.core$namespace/invokeStatic at core.clj(1603)
              clojure.core$namespace/invoke at core.clj(1597)
        cljs.compiler$emit_var/invokeStatic at compiler.cljc(448)
              cljs.compiler$emit_var/invoke at compiler.cljc(442)
        cljs.compiler$fn__3341/invokeStatic at compiler.cljc(489)
              cljs.compiler$fn__3341/invoke at compiler.cljc(489)
                clojure.lang.MultiFn/invoke at MultiFn.java(229)
            cljs.compiler$emit/invokeStatic at compiler.cljc(202)
                  cljs.compiler$emit/invoke at compiler.cljc(182)
           cljs.compiler$emits/invokeStatic at compiler.cljc(209)
                 cljs.compiler$emits/invoke at compiler.cljc(204)
           cljs.compiler$emits/invokeStatic at compiler.cljc(229)
               cljs.compiler$emits/doInvoke at compiler.cljc(204)
                clojure.lang.RestFn/applyTo at RestFn.java(157)
            clojure.core$apply/invokeStatic at core.clj(665)
                  clojure.core$apply/invoke at core.clj(660)
           cljs.compiler$emits/invokeStatic at compiler.cljc(210)
                 cljs.compiler$emits/invoke at compiler.cljc(204)
        cljs.compiler$fn__3828/invokeStatic at compiler.cljc(1382)
              cljs.compiler$fn__3828/invoke at compiler.cljc(1374)
                clojure.lang.MultiFn/invoke at MultiFn.java(229)
            cljs.compiler$emit/invokeStatic at compiler.cljc(202)
                  cljs.compiler$emit/invoke at compiler.cljc(182)
           cljs.compiler$emits/invokeStatic at compiler.cljc(209)
                 cljs.compiler$emits/invoke at compiler.cljc(204)
           cljs.compiler$emits/invokeStatic at compiler.cljc(223)
                 cljs.compiler$emits/invoke at compiler.cljc(204)
             clojure.lang.AFn/applyToHelper at AFn.java(160)
                clojure.lang.RestFn/applyTo at RestFn.java(132)
            clojure.core$apply/invokeStatic at core.clj(665)

if you (let [remote *remote*]) and use the local binding on either side in the cond, it compiles fine, ditto if the var's original value does not involve the js namespace

known issue, or should I report it in Jira?

Is there any work (even if not as well established as cider / cursive) on building a fully self hosting cljs IDE using Klipse ? [also pinging @viebel ]

@christian767 Probably the same as https://dev.clojure.org/jira/browse/CLJS-3068 If you are inclined to try the patch, it would help confirm that it is not a separate issue.

If you go down that path, this might help http://blog.fikesfarm.com/posts/2016-02-22-trying-clojurescript-paches.html

@mfikes yup, works with that patch 👍

glad I didn't have to debug that one, the behavior I experienced was pretty esoteric 😅

Thanks for checking! I suspect that, with the nature of the patch, a workaround might be to qualify the symbol used in the test. So, in your example, something like

(cond
  my.namesapace/*remote* (println *remote))

This sucks, but is the most minimal change I can think of to work around.

I used a let, which worked also

Yeah, because then the test is on a local, which is another way to workaround.

I see

Bad bug. Ugh.

yeah, not good

awesome work though 🙂

Thanks for reporting! Vote for the ticket. Otherwise I suspect it will be going through relatively soon regardless.

will do!

I'm also seeing intermittent "can't take macro clojure.core/and as value" errors in code that has worked for a long time after upgrading to 520

e.g. in (when (and js/window.something js/window.someOtherThing ...))

I think that's a Figwwheel issue

right

I suspected as much, as it's not consistent

I thought it had been isolated to Figwheel; I don't see any tickets on it though.

I’m just learning ClojureScript. One thing I can’t sort out in my head is the repercussions of translating from Clojure to JS vs Clojure to JVM bytecode. The latter seems OK because it’s at least VM machine code. However, I’m concerned about the problems that may come up when going through another high-level language (i.e. JavaScript). Has any one written about the practicalities of this and provided arguments for why it’s OK or not-OK? Keep in mind, I’m not an expert, I’m just trying to sort-out if I like the philosophy or not before diving in. Some things I’m concerned about: • debuggers keeping track of the right instruction executing • debugging through two languages (do people sometimes need to read the JS to understand an issue?) • source code management: is the emitted JS an artifact that needs source control? • readability when uploaded to places like AWS Lambda

I believe Source Maps address your first and second point (https://clojurescript.org/reference/source-maps). IMO treat the emitted source code the way you would treat binaries or JAR files. As far as readability of the compiled output, you’re probably going to have a bad time. ClojureScript isn’t CoffeeScript. The Google Closure compiler does some fantastic optimizations that result in inscrutable output.

@dcreno I loved this talk: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript, it’s quite related to your question regarding considering JS as a programming language vs bytecode.

Macros aside, will the same ClojureScript program compiled with the same version of ClojureScript result in the same JavaScript output?

The minification process is non-deterministic

AFAIAA

AFAIK, Google Closure Compiler should be deterministic

https://groups.google.com/forum/#!topic/closure-compiler-discuss/9pJ-tuGtnvM

hah TIL... Not sure if I'd depend on it though in CLJS

I can't think of a reason why the compilation process wouldn't be deterministic, as long as you're not doing IO/side-effects when it's doing the reading

I guess from a cache invalidation perspective, you could use that level of determinacy. But I think minor changes will probably cause large changes to munged name mappings. Enabling :stable-names true in the compiler options will reduce name churn between advanced compiles.

Yeah, I guess the question would be if the CLJS compiler output is deterministic. And with gensym and things like it I'm not so sure about that.

Also notice that in the mailing list post above the OP mentions simple optimizations and not advanced which is what you'll usually use. Closure might still be deterministic but these messages aren't about exactly the same thing that we do in ClojureScript.

@victorbjelkholm429 more or less I think modulo gensym as mentioned

@dcreno 3) I would not put JS in source control 4) https://github.com/serverless-heaven/serverless-webpack/issues/228

I think your comments about source mapping are perhaps a bit theoretical and don't really translate to practice - hardly anyone is debugging the generated source

that said we didn't have source mapping for almost 2 years - so that's what people used to do

since the code we generate is very regular it's possible to do - but it does take some getting used to

it gets harder of course if you're using a code transformation heavy thing like core.async a lot - which you probably shouldn't do anyway 🙂

anecdotally I don't see many complaints about debugging ClojureScript so I think source mappping + cljs-dev tools are probably working pretty well for most people

I have a small UI library I am working on. I would like to control the surface area of my API so instead of developers having to import components like this:

[ui-lib.components.comp-1 :as comp-1]
[ui-lib.components.comp-2 :as comp-2]

comp-1/comp-1
comp-2/comp-2

[ui-lib :as ui]

ui/comp-1
ui/comp-2

(ns ui
  [ui-lib.components.comp-1 :as comp-1])

(def comp-1 comp-1/comp-1)

I would move the metadata and docstrings to the API ns

migrating that stuff across nses by other means is yucky IMO

Thanks! Would you say what I am trying to do is something generally discouraged?

@tkjone, there is potemkin import-vars for clojure. As a learning exercise, I am porting this to cljs within the context of rewrite-cljs (not done yet). But I would listen to @dnolen, I’m just learning, he’s the wizard.

@dnaeon Thanks! I agree, I did not want to go too far down that path at this point. Would you say this, reducing the API surface areas as I am doing, is going against idiomatic clojure, or its just a preference thing that is fine to explore in moderation?

reducing the api surface is a fine goal

but I think manually putting that api surface together is fine

I don't know why people need tools for this

if the api surface was huge like AWS or something I would use codegen

and not bother with vars or macros

After working on the cljs version of this for a while, I think I see your point. When there is a problem with the magic macro, a lot of time can be wasted.

if I recall, I think Zach might have originally created import-vars for dealing with OpenGL - which has a similar surface issue - but import-vars is just one way to deal with that problem - and not obviously a good one to me

Good discussion on it here: https://groups.google.com/d/msg/clojure/Ng_GXYSrKmI/q0cxahB3BAAJ

Oh, this import-vars controversy goes way back: https://groups.google.com/forum/#!msg/clojure/NX_H16r4JY8/6qantiC_8iIJ