This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-01-25
Channels
- # announcements (4)
- # babashka (58)
- # beginners (21)
- # calva (42)
- # clj-kondo (15)
- # cljdoc (16)
- # cljs-dev (11)
- # clojure (57)
- # clojure-denmark (1)
- # clojure-europe (24)
- # clojure-france (4)
- # clojure-nl (1)
- # clojure-norway (16)
- # clojure-spec (6)
- # clojure-uk (2)
- # clojurescript (19)
- # clr (4)
- # conjure (1)
- # core-logic (3)
- # cursive (5)
- # data-science (2)
- # datascript (6)
- # datomic (3)
- # emacs (4)
- # events (3)
- # fulcro (17)
- # gratitude (2)
- # hyperfiddle (4)
- # introduce-yourself (3)
- # jobs-discuss (2)
- # lsp (27)
- # malli (22)
- # pathom (73)
- # portal (21)
- # re-frame (5)
- # releases (1)
- # vim (8)
- # xtdb (28)
Is it possible to avoid getting a compilation error without needing to fully qualify all non-shared keywords in a cljc file?
(:require
#?(:clj [some.clj-ns :as clj-ns]
:cljs [some.cljs-ns :as cljs-ns]))
(def hello
#?(:clj ::clj-ns/hello
:cljs ::cljs-ns/hello))
Haven't tested, but perhaps:
(:require
#?(:clj [some.clj-ns :as clj-ns :as-alias kw-ns]
:cljs [some.cljs-ns :as cljs-ns :as-alias kw-ns]))
(def hello ::kw-ns/hello)
As long as you use the same alias in both clj/cljs, you can get around it. But in the case where the clj branch uses a namespace that doesn’t appear in cljs, it doesn’t work. Another workaround seems to be to just create an empty cljs file for whatever namespace is used in the clj branch. The linter dislikes this solution, but it does make the compiler error go away.
Yeah, but have you tested it? Because in the example above I'm relying on :as-alias
and not on :as
.
Although, that should also be irrelevant and "just work" because the actual keyword uses an alias that should exist under both CLJ and CLJS.
Ah, sorry I didn’t spot that. How about this situation:
(:require
#?(:clj [some.clj-ns :as clj-ns]))
#?(:clj (def hello ::clj-ns/hello))
Reader conditionals still read everything. Auto resolved keywords require namespace alias state to resolve. Thus, any auto resolved keywords anywhere require aliases to exist (even if the read expression is not used).
Perfectly logical, but somewhat undesirable when the CLJ/CLJS isn’t completely symmetrical.
There is an ask Clojure question about this and it’s maybe something that could change, but not sure
The workarounds available seem to be, • Fully qualify • Create an empty CLJS file of whatever namespace is causing the problem
Btw, amazing that you’ve indexed the Ask Clojure DB in your head @U064X3EF3
AlexGPT3 has been trained on a complete data set of Clojure issues
and is retrained continuously, i imagine 😂
Another option: • Don't use autoresolved keywords
Yeah, that’s what I meant with “fully qualify”. It’s the most reasonable option, but gets a little tedious with things like :com.wsscode.pathom3.connect.operation/input
.
You could also def
it and use the var name to lower the tedium.
This is the interop reference https://cljdoc.org/d/clojure-interop/cljs-web-api/1.0.10/api/js.Float32Array , and I can find a from
function, but not something that works as a to