clojurescript

ClojureScript, a dialect of Clojure that compiles to JavaScript http://clojurescript.org | Currently at 1.10.879
raspasov 2021-03-26T00:07:54.282300Z

FYI, ClojureScript also has (cljs.core/random-uuid)

🙏 1
raspasov 2021-03-26T00:09:11.282500Z

But Clojure does not have this function in clojure.core

raspasov 2021-03-26T00:10:11.282700Z

For Clojure:

(java.util.UUID/randomUUID)

pez 2021-03-26T09:53:55.292900Z

In something we call an observer in our app, we trigger a re-frame subscription to happen only for the side-effect of having the rest of the code run. I’m hunting a bug in there but started to wonder about wether the way we do this thing could potentially stop working. So it happens in a let box:

...
(let [...
      _ @(rf/subscribe [:something])
      ... ]
...
My worry is that this could fall victim for tree shaking. Anyone knows if that could happen? This code works in our production builds, which are currently produced using Leiningen cljsbuild once prod, so … I don’t understand the compilation process well enough to know if I should stop worrying or act on the worry. 😃 I hope to be able to move the production build over to shadow-cljs which we recantly have started using in development, if that makes any difference for if I should worry or not.

jkxyz 2021-03-26T10:25:17.293Z

let -bound variables aren’t DCE’d by the compiler (at least I would be very very surprised if they were). I’d try to verify that the subscription is being updated, maybe put a prn in the component to show you every time a render occurs, and in the subscription handler to print out the new value. Also be sure that you’re deref’ing the subscription inside of the Reagent render function, not like (let [_ @(rf/subscribe ,,,)] (fn [props] ,,,))

p-himik 2021-03-26T10:25:18.293200Z

> Anyone knows if that could happen? It could not. It has side-effects.

p-himik 2021-03-26T10:26:05.293400Z

It has nothing to do where the line is exactly - in let, in an unused def, within the let body just as a free line, anywhere else. It won't be removed.

pez 2021-03-26T10:43:22.295Z

Awesome. I know it is working, so no worries there. I just wanted to know that it will keep working. 😃

Helins 2021-03-26T11:04:43.297500Z

This is purely about aesthethics but I don't suppose there is a way to turn off that sort of warnings? The fact that the compiler munges a name that is a reserved keyword:

compiler- warning: Namespace helins.void contains a reserved JavaScript keyword, the corresponding Google Closure namespace will be munged to helins.void$

thheller 2021-03-26T11:17:38.297800Z

@adam678 :warnings {:munged-namespace false} in the compiler options

Helins 2021-03-26T11:20:50.298900Z

@thheller Thanks! This is rather safe, isn't it? It seems important only for accessing it directly from JS

thheller 2021-03-26T11:21:43.299100Z

yes

👍 1
oliver 2021-03-26T11:39:57.301200Z

Salut. I'm using shadow-cljs + refactor-nrepl. cljr-clean-ns in cljr-refactor.el then cleans up the namespace's requirements, but that doesn't play nicely with npm imports (https://github.com/clojure-emacs/clj-refactor.el/issues/476). I saw that that lib has configuration :prune-ns-form (https://github.com/clojure-emacs/refactor-nrepl#configuration), which disables the pruning entirely. I've built refactor-nrepl locally with the default set to false, included it via deps.edn to verify this. Is there a simpler way to set that configuration? Either via shadow-cljs.edn or some separate config file? I dug through a few documentations, but I couldn't figure it out. Maybe there's a general way to do this that I don't know?

oliver 2021-03-28T14:10:49.317Z

Anyone got an idea how this could be configured?

knubie 2021-03-26T22:11:28.302700Z

is it possible to access clojurescript vars in a clojure macro?

thheller 2021-03-27T08:53:07.305900Z

answered on http://ask.clojure.org