This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-02-12
Channels
- # aleph (22)
- # aws (7)
- # babashka (17)
- # beginners (69)
- # chlorine-clover (9)
- # cider (2)
- # clj-kondo (3)
- # cljdoc (30)
- # clojure (113)
- # clojure-dev (30)
- # clojure-europe (11)
- # clojure-italy (2)
- # clojure-nl (16)
- # clojure-spec (1)
- # clojure-sweden (3)
- # clojure-uk (17)
- # clojurescript (77)
- # cryogen (12)
- # data-science (5)
- # datomic (27)
- # duct (2)
- # emacs (37)
- # fulcro (24)
- # graphql (2)
- # kaocha (1)
- # lambdaisland (27)
- # leiningen (4)
- # off-topic (15)
- # onyx (1)
- # other-lisps (3)
- # re-frame (94)
- # reagent (2)
- # reitit (20)
- # ring (1)
- # shadow-cljs (66)
- # spacemacs (5)
- # sql (59)
- # tools-deps (140)
- # vim (1)
- # xtdb (17)
how to disable eval loader mode, can't find it in the user guide, asking for educational purposes i need to turn evalLoad inlining off
+ Made a plain react-native example with re-frame. Forked off thheller's reagent example. Might be handy to anyone wanting this stack without Expo. https://github.com/Quezion/re-frame-react-native
@royalaid yeah thats a problem. if I could go back in time I'd slightly change the namespacing system in CLJS since the nested stuff actually is causing more issues than it helps with but yeah its too late for that.
this is embarrassing, but I get
Compiling ...
Execution error (ClassNotFoundException) at jdk.internal.loader.BuiltinClassLoader/loadClass (BuiltinClassLoader.java:582).
com.google.common.collect.Streams
upon shadow-cljs compile app
I am using it with {:deps true}, and got it from the very beginning, while calling watch
, but then it magically got fixed by calling compile once.
for deps.edn I'm not sure, probably clj -Stree
(remember to enable all aliases you might have)
plus, it sounds naive, but it is strange to me to see java dependency conflict by installing js lib
mb unrelated question: what is the best practice to keep js and java(clj) deps separated in deps.edn when using shadow?
Iām using two aliases :backend
and :web
with almost all deps defined within the alias (`:extra-deps`) and the source directories in :extra-paths
. You can put common deps or shared sources in the top level :paths
and :deps
.
In shadow-cljs.edn
:
:deps {:aliases [:web]}
works for me and plays along nicely with Cursive IDE in IntelliJ IDEA. (hint: in cursive you need to enable your aliases in the deps panel).Is this a general advice? I separate clj and cljs via aliases in deps.edn and it works fine.
so do you really separate them or do you have top-level :deps
and then a :cljs
alias on top that inherits all the CLJ deps?
deps.edn is totally fine for CLJ/CLJS. you just have to sometimes sort out dependency conflicts
This way it is just convenience to have backend and frontend in one project and IDE workspace. Probably not of an issue when using emacs or vim.
yeah I have created "fake" dependency project.clj
file before that just included ALL dependencies but wasn't actually used for anything
will rum
show up in clj deps too? e.g. "for server-side rendering". or should I dep it both in shadow and in deps.edn? as rum is cljc lib
you can only use one. *MY* recommendation is to use shadow-cljs.edn
to declare CLJS dependencies and then deps.edn
or project.clj
for CLJ. yes there may be some overlap and things declared in both but that is not an issue
OR you can use deps.edn
with a :cljs
alias and a :clj
alias with a common :shared
one
but that is a bit cumbersome to use and might not actually save you from such conflicts
so if I will not solve the dependency jvm conflict, but move all cljs deps to shadow.edn, and will not use {:deps true} - js compilation should work, right?
but yes moving all your CLJS related dependencies to shadow-cljs will most likely resolve the issue
unless you add the one that is causing the actual problem ... then you are back where you started
I haven't used deps.edn in a while ... maybe there is some easy way to make it tell you about version conflicts
I dont have datomic there. it'd be nice to make js compilation and jvm dep conflict - 2 separate issues. so moving deps over to shadow.edn now
I'd at least try running clj -Stree
once and see which guava version you get and from what
ok, moving dependencies worked. so I can take care of conflict a bit later. Thank you again.
The example at https://github.com/highcharts/highcharts-react#example-with-custom-chart-component uses this:
import Highcharts from 'highcharts/highstock'
I can confirm that it's working at https://stackblitz.com/edit/react-4ded5d?file=index.js (at least, in Firefox).
The table at https://shadow-cljs.github.io/docs/UsersGuide.html#_using_npm_packages says that anything that looks like import defaultExport from "module-name";
should be written as (:require ["module-name" :default defaultExport])
.
I required this:
["highcharts/highstock" :as Highcharts-as]
["highcharts/highstock" :default Highcharts-default]
In runtime, Highcharts-as
is the desired object, and Highcharts-default
is undefined.
Any idea why is there a discrepancy for this particular module?read the section about default https://shadow-cljs.github.io/docs/UsersGuide.html#_about_default_exports
Do you think it makes sense to add a *
to that table? Otherwise, it's not that clear that there are exceptions if you don't read further since the table appears like the ultimate authority.