Fork me on GitHub
#shadow-cljs
<
2018-02-06
>
cmal07:02:23

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.

cmal07:02:11

Does this relate to react-flip-move uses cljsjs?

cmal07:02:06

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.

thheller09:02:49

@lilactown not yet. totally forgot about node tests šŸ˜›

cmal09:02:04

What a beautiful user guide! good job @thheller! Waiting this for long!

thheller09:02:01

(ns cljsjs.react-flip-move
  (:require cljsjs.react
            cljsjs.react.dom
            ["react-flip-move" :as flip-move]))

(js/goog.exportSymbol "FlipMove" flip-move)

thheller09:02:11

+ npm install react-flip-move should do it

orestis09:02:16

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?

thheller09:02:11

@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.

orestis09:02:17

@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ā€¦

thheller09:02:09

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.

thheller09:02:54

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

thheller09:02:29

but that is all just tooling related, the language itself is standard.

thheller09:02:23

I have been doing this for a long time and sometimes implement "experimental features" first that eventually make it into CLJS itself

thheller09:02:04

which was in then shadow-build about a year before it landed in CLJS itself

thheller09:02:18

contributing to CLJS itself is pretty painful and slow so I eventually stopped and did it all in my tool directly

orestis09:02:42

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!

thheller09:02:57

eg. https://dev.clojure.org/jira/browse/CLJS-2376 is already in shadow-cljs, still waiting for patch acceptance in CLJS core ...

orestis10:02:13

Out of curiosity, once a feature lands in CLJS, does shadow move to depend on that (while exposing the same API)?

thheller10:02:26

when it makes sense yes

thheller10:02:28

I initially started all of this because I wanted :modules support in CLJS

orestis10:02:20

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.

thheller10:02:21

but integration is still not great in CLJS

thheller10:02:19

well my opinion is that shadow-cljs is a build tool and CLJS should focus on language features

thheller10:02:45

IMHO there is too much tooling in CLJS itself that is half broken and unreliable

thheller10:02:56

so instead of building on that it replaces everything tooling related

orestis10:02:20

From what I can remember, the only time where there is a shadow reference in your code is when using the dynamic loader features?

thheller10:02:45

again shadow.loader existed about a year before cljs.loader ...

orestis10:02:14

(Yep, I understand that ā€” itā€™s just that I read the CLJS docs first šŸ˜‰ )

thheller10:02:30

cljs.loader unfortunately has some unsolvable issues which is why I don't recommend using it

thheller10:02:51

yeah docs were the biggest weakness of shadow-cljs which is why I now document everything first

thheller10:02:54

or try to anyways šŸ˜‰

orestis10:02:25

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.

orestis10:02:58

The shadow docs are fantastic, BTW. Itā€™s just that to an outsider I just didnā€™t get the rationale immediately.

thheller10:02:05

yeah code loading is tricky since it really needs build tool support

thheller10:02:46

yeah I will add a Rationale section to the docs definitely

orestis10:02:10

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ā€¦

orestis10:02:51

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!)

Jon11:02:32

Can we keep a FQA for this kind of questions? Maybe on ClojureVerse or GitHub issues, and with an index page somewhere... @thheller @orestis

thheller11:02:11

trying to write a section for the docs that explains the differences (and rationale)

orestis11:02:49

@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)

Jon11:02:47

we can still link questions/answers to UserGuide from that index though...

Jon11:02:51

BTW I got these configs on my Nginx:

Jon11:02:55

server {
  server_name  ;
  location / {
    deny all;
  }
  rewrite ^/(.*)$  permanent;
}

Jon11:02:22

if someone happens to use , he/she will be redirected to UserGuide.

mynomoto14:02:25

@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.

mynomoto15:02:09

Is there any vim users of shadow-cljs with an working config to connect to the repl?

tungsten19:02:51

has anyone used material-ui/material-ui-next directly from npm with shadow-cljs?

thheller19:02:08

I did a few tests with material-ui while ago yes, did not try next

thheller19:02:13

@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

thheller19:02:18

so always try to include components directly. (:require ["material-ui/Card" :default Card :refer (CardHeader)]) and such

thheller19:02:41

instead of importing "material-ui" and picking apart that object

thheller19:02:17

they also ship pure ES6 it seems so (:require ["material-ui/es/Card" ...]) should also work

thheller19:02:06

avoid (:require ["material-ui" ...]). should save a ton of bytes unless you are actually using everything

tungsten19:02:39

thanks thheller. Does this work better than the vanilla cljs compiler

tungsten19:02:28

is this by infering externs? just trying to understand

thheller19:02:32

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)

thheller19:02:06

externs inference helps too though

tungsten19:02:10

how do you integrate shadow-cljs with a full stack clj/cljs project

thheller19:02:44

should cover everything you need

tungsten19:02:44

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

thheller19:02:30

lein :aliases {"build-uberjar" ["do" ["run" "-m" "shadow.cljs.devtools.cli" "release" "your-build"] "uberjar"]}

thheller19:02:28

bash or make or anything really shadow-cljs release your-build && lein uberjar

mynomoto20:02:00

@thheller Dominic over #vim-fireplace told me that you could have the incantation to get a cljs-repl working on vim using shadow-cljs.

thheller20:02:24

I had it once but completely forgot how it worked

thheller20:02:34

can you connect to the nrepl properly?

dominicm20:02:04

@thheller I recall there was a function to call for the repl-env

thheller20:02:35

shadow-cljs watch the-build then in vim :Connect and :Piggieback :the-build?

dominicm20:02:55

That's the one

mynomoto21:02:06

That worked mostly. I can jump to definitions and namespaces but show docs returns an error. Thanks, that will get me going.

thheller21:02:57

you might need cider-nrepl on the classpath? not sure if the vim stuff uses that

mynomoto21:02:26

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.

mynomoto21:02:48

I think fireplace adds that, but I will check, thanks.

thheller21:02:09

arent react addons deprecated?

thheller21:02:05

otherwise for test/prod stuff you control it all via the namespaces that are required

thheller21:02:19

for dev you typically add :preloads

lilactown22:02:12

ā¤ļø

lilactown22:02:57

Iā€™m guessing I need to pull down the latest version of shadow-cljs?