This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-03-26
Channels
- # announcements (3)
- # architecture (53)
- # babashka (6)
- # beginners (101)
- # bitcoin (3)
- # calva (4)
- # cider (3)
- # clara (7)
- # cljdoc (2)
- # cljsrn (14)
- # clojure (104)
- # clojure-europe (96)
- # clojure-germany (21)
- # clojure-nl (6)
- # clojure-serbia (3)
- # clojure-spain (1)
- # clojure-uk (13)
- # clojuredesign-podcast (4)
- # clojurescript (14)
- # cursive (5)
- # data-science (19)
- # datomic (16)
- # emacs (15)
- # fulcro (33)
- # graalvm (5)
- # honeysql (3)
- # instaparse (2)
- # jobs (3)
- # lsp (82)
- # malli (2)
- # off-topic (11)
- # pedestal (4)
- # polylith (62)
- # practicalli (4)
- # shadow-cljs (56)
- # tools-deps (53)
- # vim (17)
- # xtdb (53)
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.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] ,,,))
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.
Awesome. I know it is working, so no worries there. I just wanted to know that it will keep working. 😃
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 Thanks! This is rather safe, isn't it? It seems important only for accessing it directly from JS
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?
Depends on what you mean by "access". It's possible to mention them so that the generated CLJS code ends up using them.
answered on http://ask.clojure.org