Fork me on GitHub
#shadow-cljs
<
2019-08-10
>
thheller05:08:20

@deadghost yes if you directly :require the namespaces will be moved to that module and cannot be code-split

thheller05:08:44

lazy-component however is just a proof of concept that combines it with React components

thheller05:08:00

you could just as well load an entire map for example if you want to group something

gerred15:08:41

does shadow support service workers today?

gerred15:08:10

i see web workers and maybe this is enough and I'm not as familiar as I'd like to be.

gerred15:08:24

an new Worker vs navigator.serviceWorker

gerred15:08:37

obviously I could still do it myself

thheller16:08:38

@gerred yes the :web-worker true option also works for service workers

gerred16:08:16

@thheller killer, thank you. would I just bind to the install/activate/fetch events? there's no higher level abstraction there yeah?

gerred16:08:26

(i wouldn't want there to be, just making sure I understand correctly)

thheller16:08:33

yeah no abstraction at all. you do everything via interop

gerred16:08:38

killer thank you

thheller16:08:02

I generally recommend using a better suited tool like https://developers.google.com/web/tools/workbox/

thheller16:08:27

since its mostly declarative type stuff

thheller16:08:07

but I've only experimented with super basic service workers so CLJS might get better the more you do (if you do)

gerred16:08:04

oh that's a good point

gerred16:08:27

yeah I'd eventually at least like to develop my own toolkit, fortunately I'm not in a position where I need to be systemic about it

tianshu16:08:22

is it possible to get the asset-path in code?

thheller16:08:41

js/CLOSURE_BASE_PATH

thheller16:08:00

oh no wait thats only for dev builds

thheller16:08:03

no there is not

tianshu16:08:09

what about to get it at compile stage via macro?

thheller16:08:35

not really no

thheller16:08:49

what do you need it for?

thheller16:08:03

I'd probably suggest using a closure-define?

tianshu16:08:30

I want write a macro which used to define style in cljs. when the macro expand, generating css file to somewhere

thheller16:08:56

side-effects during compilation are not a good idea

thheller16:08:24

eg. they break caching

tianshu17:08:13

if some cljs using this macro is already compiled, it will be cached and won't compile again?

tianshu17:08:22

but does it matter if this macro will be used only in application code, not used as a dependency for library

thheller17:08:33

depends on how you end up doing things

tianshu17:08:56

I want to generate css, with following features 1. always keep the class property sync with the selector in css. 2. less runtime stuff, as static as possible 3. manipulate style with functions

thheller17:08:59

you can do it of course. I just don't reocmmend doing side effects during macro expansion

thheller17:08:59

you can look at the impl of that maybe

thheller17:08:23

doesn't generate extra .css files but instead injects the css at runtime

tianshu17:08:25

very similar to my demand

tianshu17:08:28

what is the proper way to invoke something in Clojure via CLJS

tianshu17:08:38

just for development convenient