Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2021-03-26

Channels

#clojurescript
<
2021-03-26
>
pez09:03:55

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.

jkxyz10:03:17

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-himik10:03:18

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

p-himik10:03:05

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.

pez10:03:22

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

Adam Helins11:03:43

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$

thheller11:03:38

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

Adam Helins11:03:50

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

or11:03:57

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?

or14:03:49

Anyone got an idea how this could be configured?

knubie22:03:28

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

p-himik06:03:34

Depends on what you mean by "access". It's possible to mention them so that the generated CLJS code ends up using them.