This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-07-20
Channels
- # aleph (4)
- # beginners (47)
- # boot (22)
- # cider (7)
- # clara (1)
- # cljs-dev (8)
- # cljsrn (21)
- # clojure (180)
- # clojure-argentina (13)
- # clojure-gamedev (1)
- # clojure-italy (5)
- # clojure-poland (4)
- # clojure-russia (17)
- # clojure-spec (19)
- # clojure-uk (33)
- # clojurescript (107)
- # cursive (61)
- # data-science (1)
- # datomic (7)
- # emacs (69)
- # euroclojure (1)
- # graphql (1)
- # hoplon (11)
- # immutant (43)
- # jobs (1)
- # leiningen (3)
- # off-topic (5)
- # om (10)
- # onyx (2)
- # parinfer (52)
- # pedestal (11)
- # re-frame (31)
- # reagent (23)
- # ring-swagger (3)
- # schema (2)
- # specter (7)
- # unrepl (9)
I was curious if using dotted symbols (outside of js/
) to access nested JavaScript object properties is correct or an abuse. A concrete example is (def x #js {:foo #js {:bar 17}})
followed by evaluating x.foo.bar
. This was made to work with https://dev.clojure.org/jira/browse/CLJS-697. Similarly (let [y #js {:foo #js {:bar 17}}] y.foo.bar)
works (I suppose we could find the code and or ticket justifying it as well).
My takeaway is that perhaps this is legit, and should be documented in the JavaScript interop page as being equally valid to more verbose constructs like (.. x -foo -bar)
On the other hand, I suspect that things like #'x.foo.bar
result in a working Var, may be simply an unintentional consequence.
@mfikes I think although undocumented nested dotted access is valid and would result in a great amount of breakage if removed
Would there be something equivalent to cljs.closure/find-cljs-dependencies
that also includes macro namespaces? I’m trying to find a way to build a dependency graph that includes macros, without actually requiring everything into a compiler state.
I can currently build this graph by requiring everything into Planck or Lumo and then crawling the compiler state for transitive dependencies, but this is tricky because some namespaces don’t actually run in Planck/Lumo (they require a browser environment), so I had to stub out *eval-fn*
with one that doesn’t throw on errors. It feels like there should be a more direct and fast way to figure this stuff out statically.
@mhuebert anything in particular you want to achieve? shadow-cljs has some functions that might help