This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-06-05
Channels
- # babashka (4)
- # bangalore-clj (1)
- # calva (5)
- # chlorine-clover (1)
- # cider (5)
- # clara (9)
- # clj-kondo (18)
- # cljs-dev (12)
- # clojure (42)
- # clojure-europe (9)
- # clojure-norway (1)
- # clojure-uk (4)
- # clojured (255)
- # clojurescript (76)
- # community-development (3)
- # conjure (4)
- # emacs (9)
- # figwheel (3)
- # fulcro (6)
- # graalvm (6)
- # java (15)
- # lsp (7)
- # luminus (1)
- # off-topic (5)
- # pathom (9)
- # reagent (5)
- # ring (6)
- # shadow-cljs (38)
- # sql (21)
- # xtdb (12)
Hello, I was looking at the code generated by reify a bit, and I have noticed that in production build it preserves the N conditionals for each namespace segment.
I have tried to implement an experimental reify variant that uses different exists?
impl, that results in a more simple checking on dev build:
if((typeof app.main.data.viewer.t_app$main$data$viewer57870 !== 'undefined')){
} else {
(app.main.data.viewer.t_app$main$data$viewer57870 = (function (){
The question here is, how troublesome can this be? In development build at the end and at the end everything loads in order, and if it does not load in order, other problems will also appear (so checking segments is it possible that it is redundant?) In the production build, access to the generated class variable is done directly, so checking the existence of variables that represent the namespace segments also looks redundant. I'm wrong?
I have tried it in a large codebase that uses reify extensively and everything is working as expected (prod and dev builds), but i want to ask here if I'm missing something evident...
somewhat related https://ask.clojure.org/index.php/8879/cljs-should-macros-support-lifting-vars-to-the-ns-level since with this reify
wouldn't need that check at all
also related https://clojure.atlassian.net/browse/CLJS-3207 😉