This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-02-06
Channels
- # bangalore-clj (2)
- # beginners (55)
- # boot (32)
- # bristol-clojurians (4)
- # cider (16)
- # clara (13)
- # cljsrn (6)
- # clojure (110)
- # clojure-india (1)
- # clojure-italy (69)
- # clojure-spec (32)
- # clojure-uk (15)
- # clojurescript (102)
- # community-development (6)
- # cursive (1)
- # datomic (9)
- # docs (2)
- # duct (1)
- # emacs (39)
- # events (3)
- # fulcro (131)
- # garden (1)
- # immutant (4)
- # jobs (1)
- # jobs-discuss (5)
- # keechma (1)
- # lein-figwheel (6)
- # leiningen (6)
- # mount (6)
- # nrepl (2)
- # off-topic (69)
- # om (54)
- # parinfer (7)
- # re-frame (63)
- # reagent (13)
- # remote-jobs (1)
- # shadow-cljs (90)
- # spacemacs (8)
- # specter (6)
- # sql (16)
- # testing (1)
- # unrepl (3)
- # vim (4)
- # yada (1)
Hi, I added [day8.re-frame/trace "0.1.18-react16"]
to my project, shadow-cljs watch app
complains
Build failure:
The required namespace "cljsjs.react-flip-move" is not available, it was required by "day8/re_frame/trace/utils/animated.cljs".
then I added [cljsjs/react-flip-move "2.9.17-0"]
to shadow-cljs.edn
, still same complains.I removed [cljsjs/react-flip-move "2.9.17-0"]
from shadow-cljs.edn
and add react-flip-move
to package.json
and create react_flip_move.cljs
in cljsjs/
and it works.
@lilactown not yet. totally forgot about node tests š
(ns cljsjs.react-flip-move
(:require cljsjs.react
cljsjs.react.dom
["react-flip-move" :as flip-move]))
(js/goog.exportSymbol "FlipMove" flip-move)
Is there a brief overview on how shadow-cljs compares with the āvanillaā CLJS compiler? Does it build on top of it (incl. recent changes for npm integration etc) or does it overlay its own machinery on top of the ācoreā CLJS->JS compiler? Or something completely different?
@orestis it does use the default CLJS compiler but replaces certain parts. the npm
integration is completely custom and none of the official code for that is used (since its too broken). so the npm/js integration is the biggest difference. a few minor tweaks to the compiler here or there.
@thheller Thanks ā are there plans to eventually merge the two or are they serving different goals? I guess Iām worried about a long-term divergence and a difficult decision to make when starting outā¦
so in theory everything is standard, that means everything shadow-cljs does should work with other tools too. in practice however that is not the case because CLJS is just broken in places. once that gets fixed you should be able to switch between shadow-cljs -> cljs without issues.
I'm doing things differently because I didn't agree with the approach taken by CLJS and didn't see an easy way too fix it
I have been doing this for a long time and sometimes implement "experimental features" first that eventually make it into CLJS itself
best example is https://dev.clojure.org/jira/browse/CLJS-948
contributing to CLJS itself is pretty painful and slow so I eventually stopped and did it all in my tool directly
Shadow looks fantastic, donāt get me wrong ā itās obvious by reading the docs that thereās a lot of well-thought features that are usable today. So thanks for all that!
eg. https://dev.clojure.org/jira/browse/CLJS-2376 is already in shadow-cljs, still waiting for patch acceptance in CLJS core ...
Out of curiosity, once a feature lands in CLJS, does shadow move to depend on that (while exposing the same API)?
that eventually also landed in CLJS http://swannodette.github.io/2015/02/23/hello-google-closure-modules
OK, so would it be fair to summarize it like so ā main CLJS development is (perhaps understandably?) slow to gain new features, esp. WRT the wider JS integration story, so shadow-cljs tries to bridge that gap, while trying (to some extent) to both profit from CLJS developments and also push new patches/ideas āupstreamā? So at least currently and in the medium term, shadow-cljs is always going to be a superset of CLJS.
well my opinion is that shadow-cljs is a build tool and CLJS should focus on language features
From what I can remember, the only time where there is a shadow reference in your code is when using the dynamic loader features?
cljs.loader
unfortunately has some unsolvable issues which is why I don't recommend using it
yeah docs were the biggest weakness of shadow-cljs which is why I now document everything first
Itās a difference though in the sense that shadow parses the various require statements its own way, while to the untrained eye you wouldnāt be able to know which build tool is used. Whereas the shadow loader is explicit.
The shadow docs are fantastic, BTW. Itās just that to an outsider I just didnāt get the rationale immediately.
https://code.thheller.com/blog/shadow-cljs/2017/09/15/shadow-cljs-introduction.html has some things
A feature comparison matrix might also be a good idea? I hope I could help out a bit more but Iām just finding my way around CLJS for hobby work, with an eye of medium-term adoption in some projects, could be more than a year awayā¦
Reading the docs again, it is really a fantastic piece of work. Iāll definitely be using shadow-cljs for my hobby projects. Great job and thanks again! (and do consider setting up a Patreon or applying to Clojurists together!)
Can we keep a FQA for this kind of questions? Maybe on ClojureVerse or GitHub issues, and with an index page somewhere... @thheller @orestis
trying to write a section for the docs that explains the differences (and rationale)
@jiyinyiyong @thheller Let me know if I can be of any help (even editing the discussion into a Q&A form that could be expanded/vetted later)
@thheller I tried the cljs-react-native-app, updated all deps to the latest from react create app and It just worked. Thank you! I will try do a PR later to update those on the examples repo.
Is there any vim users of shadow-cljs with an working config to connect to the repl?
@bfast one thing to note about material-ui is that they provide an index file which includes everything but acessing individual components is also possible
so always try to include components directly. (:require ["material-ui/Card" :default Card :refer (CardHeader)])
and such
they also ship pure ES6 it seems so (:require ["material-ui/es/Card" ...])
should also work
avoid (:require ["material-ui" ...])
. should save a ton of bytes unless you are actually using everything
no. shadow-cljs handles npm packages very differently and doesn't use anything from the :npm-deps
functionality in CLJS (since it doesn't work)
if you have lein
setup already you can do it via https://shadow-cljs.github.io/docs/UsersGuide.html#embedded
It would be nice if there was a plugin similar to lein cljsbuild... so that shadow-cljs could be invoked as part of the build process for generating an uberjar
lein
:aliases {"build-uberjar" ["do" ["run" "-m" "shadow.cljs.devtools.cli" "release" "your-build"] "uberjar"]}
@thheller Dominic over #vim-fireplace told me that you could have the incantation to get a cljs-repl working on vim using shadow-cljs.
That worked mostly. I can jump to definitions and namespaces but show docs returns an error. Thanks, that will get me going.
Is there an example somewhere with different test and and prod dependencies? I'm thinking something like using react-with-addons
for testing and plain react
for prod.
otherwise for test/prod stuff you control it all via the namespaces that are required
@lilactown I just added the missing :node-test
target. See https://shadow-cljs.github.io/docs/UsersGuide.html#target-node-test