Fork me on GitHub
#shadow-cljs
<
2019-12-05
>
indy11:12:46

Hey All, How do I use the Garden library to generate the CSS and then include it in my project? I understand (css [:h1 {:font-weight "bold"}]) will output the appropriate CSS string, but how do I create a CSS file from this and include it in my ClojureScript project? I'm using shadow-cljs as my build tool

indy11:12:24

For Leiningen there is lein-garden that will handle the cljs->css compilation

deas11:12:50

Appears devcards is relying on global React (which is not what you get by default). What are you guys using instead? Storybook?

thheller11:12:16

@deas you can require cljsjs.react before including devcards

πŸ‘ 4
thheller11:12:21

that creates the shim global

thheller11:12:42

@kslvsunil I don' know. I've never used garden myself.

thheller11:12:35

lein-garden looks like it only supports clojure though?

thheller11:12:14

@deas might also need cljsjs.react.dom. I don't know why devcards doesn't require them directly itself

deas11:12:19

@thheller Appears devtools does not get much ❀️ these days. We don't have much to loose yet, so I guess it is time to depart now.

Filipe Silva11:12:37

@deas https://github.com/filipesilva/create-cljs-app has an example of using devcards with react testing-library on shadow-cljs

Filipe Silva11:12:08

it's true that devcards doesn't get a lot of attention, but I don't think storybook fills the same use case

Filipe Silva11:12:29

devcards is more exploratory, whereas storybook is more catalog-y

πŸ‘ 4
thheller11:12:36

storybook also doesn't match CLJS very well since it expects to work with ESM code

πŸ‘ 4
Filipe Silva12:12:15

@thheller how should devcards be importing react to be compatible with shadow-cljs by default? I can open an issue there. I think it's likely that devcards will need to get a version out soon because it doesn't support newer react versions well, and will want to include the newer reagent that does.

thheller12:12:11

just (:require ["react" :as react]) should work. I believe the newer cljsjs/react packages have that setup correctly to emulate

thheller12:12:43

not sure though. haven't used default CLJS since forever ago πŸ˜›

deas12:12:04

Sorry for the noise, but appears I am running into every brickwall one could imagine ... 😒

deas12:12:29

Running compilevia lein :aliases ẁorks ... until it does not when calling the alias from :prep-tasks. Seems this signature error is not uncommon. Any suspect about the possible culprit?

Note: Recompile with -Xlint:unchecked for details.
Syntax error (NoSuchMethodError) compiling at (shadow/cljs/devtools/api.clj:1:1).
com.google.common.base.Preconditions.checkState(ZLjava/lang/String;Ljava/lang/Object;)V

thheller13:12:28

@deas thats a dependency conflict. looks like guava.

deas13:12:34

Moving [thheller/shadow-cljs "2.8.80"] from :dev profile to default deps gets around it, but guess I don't want shadow-cljsending up in the (uber)jar.

thheller13:12:32

well I recommend using shadow-cljs.edn for reasons such as this

thheller13:12:52

but you can certainly resolve it in lein. just can't help you much.

deas13:12:14

Already got that. Actually, it was the moment I understood why you suggest it.

deas13:12:51

Dependency Hell(er). Sorry, could not resist. πŸ˜‰

sheepy 4
thheller13:12:31

I believe one of the culprits is datomic using an older guava version than the closure compiler

thheller13:12:52

and the closure compiler being unhappy if it runs with an older guava version

deas13:12:21

Datomic issues propagate all the way down to ... me? WTF? πŸ˜‰

deas13:12:14

Feels like navigating a mine field. :collision:

thheller13:12:36

thats why I keep my CLJS separate builds separate from my CLJ builds πŸ˜‰

deas13:12:54

Very reasonable. Now may be the time for me to swallow even more ...

thheller13:12:51

in the past I have done :backend and :frontend profiles in lein. that works reasonably well too

deas13:12:37

Also good point. Guess I better go out for a walk with the 🐢 and think about that for a moment. We still have a huge mess to untangle ahead of us ...

deas13:12:13

Actually, I expected to finish shadow-cljs migration today. Now I find there is a whole lot of yak to shave.

thheller13:12:00

which CLJS version did you use before? the closure compiler guava problem should have existed with plain 1.10.520 too I think

deas13:12:37

All things latest and greatest, so 1.10.597

deas13:12:17

Appears it is not uncommon to weed out transitive clojurescript deps. tumbleweed