Fork me on GitHub
#shadow-cljs
<
2018-05-04
>
steveb8n00:05:39

@fj.abanses @thheller thanks for the feedback. that helps me prioritise what gets done next

👍 4
verma01:05:07

@thheller it is absolute path, <link rel="stylesheet" href="/css/main.css">, I had a few issues to begin with, with electron development, first thing was that it couldn't figure the WS url, since I was opening the file using file:// URL and it was expecting http(s). But I suspect that issue isn't related to this (may be). I run the shadow-cljs dev server and open the URL from electron.

verma01:05:49

everything seems to work fine, code reloading is working as expected, but changing the CSS does nothing. I turned on :verbose and :debug mode for shadow-cljs, to see if it prints any log messages etc. but still quiet. Whenever a code change is made however, its super quick and I see changes immediately 😕

dima07:05:13

Does shadow-cljs support :aliases of deps.edn? https://clojure.org/reference/deps_and_cli#_aliases It doesn’t see dependencies provided in :extra-deps as i don’t have way to specify which alias it should be using

dima08:05:32

@thheller thanks, somehow missed that example with aliases

grounded_sage08:05:41

Can shadow-cljs do SSR I've just been searching and can't find much info regarding SSR and shadow cljs?

mitchelkuijpers08:05:05

@grounded_sage What would you need from shadow-cljs to do SSR? I am not quite sure what you mean.

thheller08:05:27

@grounded_sage shadow-cljs only builds your JS it doesn't run any for you. you can build JS that does SSR perfectly fine though.

grounded_sage08:05:51

I'm just wrapping my head around how it all sort of fits in. Currently reviewing Gatsby JS to see if the community plugins and ecosystem is worth using as a default for smaller work. Though my current thoughts are still that it would be better to stick with CLJS

thheller08:05:37

you can probably use gatsby directly with :npm-module

grounded_sage08:05:58

Hmm I didnt even think about that..

thheller08:05:59

hmm maybe not

thheller08:05:09

forgot that it uses the file paths for stuff

thheller08:05:13

that probably won't work

grounded_sage09:05:11

yea well tbh there isn't much of Gatsby that I couldn't recreate. I'm just mentally figuring out what is missing from my current workflow that helps me get the performance and workflow similar to Gatsby

grounded_sage09:05:02

I'm not interested in recreating Gatsby as a whole. Just an environment focused on perf basically.

thheller09:05:07

well you could always use gatsby and just create the pages/*.js manually and require the CLJS code from them

kurt-o-sys10:05:17

just wondering: if I have environment specific configuration (sources), how to do this in shadow-cljs (I'm porting a project from lein to shadow-cljs)? Should this work

{:source-paths ["src"]
 ...
 :builds {:app {:target           :browser
                :output-dir       "resources/public/js"
                :asset-path       "/js"
                :modules          {:main
                                   {...}}
                :dev              {:source-paths ["env/src/dev"]}
                :prod             {:source-paths ["env/src/prod"]}
                :compiler-options {:closure-warnings {:global-this :off}
 
?

thheller10:05:48

not possible since I consider this a bad anti-pattern

kurt-o-sys10:05:07

oh, ok... so, how to do environment-specific configs? 😛

thheller10:05:32

what in particular?

thheller10:05:12

I typically recommend building out your production app and structure the code that way

kurt-o-sys10:05:22

well, for example, connections to test or prod api's

thheller10:05:26

than "add" additional code via :devtools {:preloads [...]}

kurt-o-sys10:05:39

oh, the build is exactly the same, it's about configs (keys, uri's, ...)

thheller10:05:04

right. those I pass into the app on startup

thheller10:05:23

<script>my.app.init(some_data_here);</script>

kurt-o-sys10:05:27

d'you use any kind of library to parse or so? Or you just pass a file name?

kurt-o-sys10:05:43

in your html?

thheller10:05:08

there are many different ways you can do this. all depends on your needs.

thheller10:05:19

:closure-defines also works

thheller10:05:35

but "dynamic" config data I pass in on startup always

thheller10:05:01

this is supported. just not for :source-paths

kurt-o-sys10:05:34

well, on startup... that's build time. The generated html/css/js is static, so it has to be there after building the app. The 'dynamic' part is: on build-time, pass the right configs.

thheller10:05:12

but you said generated html

thheller10:05:23

so you can generate that html to include the config?

kurt-o-sys10:05:59

yeah... I guess closure-defines is what I need

thheller10:05:09

you have several different options to do any of this

thheller10:05:17

really depends on what you are doing exactly

kurt-o-sys10:05:25

(urls etc, nothing extremely secret here, just different in prod or dev)

thheller10:05:47

via HTML is the definitely the best option IMHO since you do not need to recompile to change the config

kurt-o-sys10:05:28

right, makes sense.

kurt-o-sys10:05:43

so, it'll be html or clojure-defines (which can be used inside :builds {:app {:dev {:clojure-defines {...}}}}, right)?

kurt-o-sys10:05:57

thx! will do.

kurt-o-sys10:05:18

most probably html - no need to recompile to change the config, I totally agree. Cool!

thheller10:05:59

I have this ancient blog post I wrote about the way I do this

thheller10:05:30

I have been using this approach for 6+ years now

thheller10:05:56

might give you some ideas

troglotit11:05:39

I'm using https://github.com/weavejester/environ with this kind of code. If you need env variables - that's the way

thheller11:05:15

thats a bad idea since it breaks caching

thheller11:05:17

the CLJS compiler and shadow-cljs is not aware of your environment variables so your code will not be recompiled if you change them

troglotit11:05:56

that's fine trade-off for me 🙂. I'm not even sure how env variables in linux/macos/posix should work regarding processes, and changing in runtime; So all of the use cases for env variables for me is where those static uri to my backend. The benefit is env variables are injectable by different kind of dockers/ci/cd

thheller11:05:29

yeah but all of them require recompilation

thheller11:05:15

if you instead pass in the config at runtime you can compile once and actually use the same output for all envs

thheller11:05:26

in CI I want to test what will actually be released

thheller11:05:33

not some special CI build

thheller12:05:25

never liked env for the same reasons I don't like bindings in clojure. it is not immediately obvious those will affect your program.

thheller12:05:11

if you run node server.js path/to/config.edn instead I can look at the config to see whats in it

thheller12:05:21

don't have to worry about some env vars being set and such

thheller12:05:46

same approach for the browser bascially. just a different way to get the config there

pez12:05:36

What do people use for unit testing with shadow-cljs node projects?

pez16:05:39

Thanks @thheller, I’ll have a think about how that can be supported in Calva.

Logan Powell17:05:51

👋 hi everyone! Newb here... I'm getting an error when trying to setup shadow with proto-repl/atom:

CompilerException java.lang.RuntimeException: No such var: shadow.cljs.devtools.api/start-worker, compiling:(null:1:1) 
the other two commands: (shadow.cljs.devtools.api/compile :app) (shadow.cljs.devtools.api/nrepl-select :app) are working flawlessly... Any ideas?

lwhorton17:05:32

i just updated to the latest shadow-cljs and am now getting “warning macro namespace reloaded” — i dug around the src files, user guide, and gh issues, but I don’t really see why this exists

thheller18:05:27

@lwhorton that shouldn't be a warning. it is fine and expected, think I left it in there when I debugged something. sorry for the confusion.

👍 4
thheller18:05:13

@loganpowell why are you calling start-worker? watch is probably what you are looking for?

thheller18:05:55

ugh. don't! thats super old.

Logan Powell18:05:36

haha ok. Thank you!

thheller18:05:07

I'll update the README. the rest still looks accurate so should be fine

Logan Powell18:05:34

Sweet. Yes, the starting block helps a bunch