Fork me on GitHub
#shadow-cljs
<
2018-03-17
>
mjmeintjes01:03:38

Hi. I have an static index.html file. Is there any support in shadow-cljs to update that on release to point to the latest js file, based on the hash generated and available in manifest.edn? I know how to do it if I have a server that serves the html, but in this case the app is client side only.

mjmeintjes01:03:30

No worries, turned out to be pretty easy using the clj-run functionality

escherize07:03:38

Hey, just curious, what's this thing for? http://take.ms/mHhEK

escherize07:03:54

Also, I'm playing around with cljs-play and shadow-cljs. Unfortunately I'm getting the error: The required namespace "p5.core" is not available, it was required by "play_cljs/core.cljs".. I tried npm install p5 which did update my package.json --- however cljs-play uses foreign libs ( https://github.com/oakes/play-cljs/blob/7fa4c33cf1cb734985366e8bdca1d7ed78546715/src/deps.cljs ) that I'm unable to satisfy using npm install p5 Any tips?

thheller08:03:07

@escherize oops thats an UI experiment I'm working on in a branch. must have accidentally published it in the jar.

thheller08:03:44

@mjmeintjes yeah clj-run is a good solution. there is nothing built-in for this (yet).

thheller09:03:29

@escherize your instinct was correct but to work arround foreign-libs an extra shim file is required. they look like this https://github.com/thheller/shadow-cljsjs/blob/master/src/main/cljsjs/d3.cljs

thheller09:03:26

so (ns p5.core (:require ["p5" :as p5])) (js/goog.exportSymbol "p5" p5). basically all they to is load the package properly from npm and export the global name that cljsjs would otherwise create

thheller09:03:08

dont know if the global is actually p5 though

cmal12:03:21

@thheller I just made a pull request to add web3.js into .

thheller12:03:50

@cmal just commented 🙂

cmal12:03:15

sorry for that.

thheller12:03:14

don't need to close the PR. if you just push a new version of your fork it gets updated.

cmal12:03:04

😅

thheller12:03:53

merged. I'll add it to the next release.

justinlee17:03:19

@thheller Juhopetri was saying that he thought react would never work without externs. How are you doing it in shadow?

thheller17:03:47

node_modules files don't go through :advanced, so you don't need externs.

justinlee17:03:24

Oh do mom-deps files go through advanced?

justinlee17:03:01

Wow that was super unclear to me

justinlee17:03:13

No wonder it doesn’t work! :)

justinlee17:03:43

I just thought it was a better foreign libs

thheller17:03:44

to be fair support is getting better and will get better over time as more people move towards ES6

thheller17:03:01

but currently its not reliable enough to use .. thats why its not the default in shadow-cljs

justinlee17:03:34

I just feel bad for people struggling to make it work who probably just want to get something working.

thheller17:03:05

yeah. the news announcement was way too premature IMHO.

bhauman18:03:02

@thheller do you think you would benefit from something like figwheel-core?

bhauman18:03:35

I had shadow in mind when I was writing it

thheller18:03:55

@bhauman besides from your ideas probably not. I have pretty much everything already.

bhauman18:03:18

well coolio

thheller18:03:55

would be nice to re-use your error reporting stuff though

bhauman18:03:26

well if you get a chance check it out

bhauman18:03:46

as it has no deps at all

bhauman18:03:51

if you do think you could use it but need changes let me know

thheller18:03:33

I think shadow-cljs is much too low level and not built on the standard cljs.closure stuff at all

thheller18:03:53

it started out as a replacement to cljs.closure and lein-cljsbuild after all

thheller18:03:05

I only added the live-reload stuff way after

bhauman18:03:13

yeah if you don't have a compiler env then it won't help much

thheller18:03:38

@bhauman while you are here. @mhuebert suggested the other day that it would be useful for libraries if they could hook into the live-reload process without the user having to configure it. eg. by adding a bit of meta to a (defn ^:on-jsload some-hook [] ...). I think you already have some special metadata in figwheel to do this stuff.

thheller18:03:02

maybe we can decide on some generic names so things work in figwheel and shadow equally

bhauman18:03:16

this is a good idea

bhauman18:03:49

but var data doesn't get pushed right??

bhauman18:03:10

does it get pushed reliably

thheller18:03:10

if shadow-cljs I have :before-load, :before-load-async and :after-load to hook into the respective points in the reload cycle

bhauman18:03:28

is that metadata?

thheller18:03:33

don't need it on the client. can just walk the compiler env when a compile finish and comb through the :defs

bhauman18:03:38

or rather config hooks

thheller18:03:00

currently only config hooks but I want to allow the metadata as well

bhauman18:03:04

yeah that relies on a compiler hook

bhauman18:03:59

have to think about this, trying to do as little on the compile side as possible now

bhauman18:03:44

actually yeah this is totally possible

bhauman18:03:03

got my head around it, its a good idea

thheller18:03:26

(for [[ns info] (::ana/namespaces compiler-env)
              :let [{:keys [defs]} info]
              {:keys [name meta] :as def} defs
              :when (:on-jsload meta)]
          [ns name])

thheller18:03:55

this should be enough to extract the info required, then just send it to the client and let it do the thing

bhauman18:03:17

yeah just have to push it with the other reload info I'm pushing

bhauman18:03:29

and they should probably label it with export as well

thheller18:03:03

nah that would keep it alive after :advanced. don't want that for dev code

bhauman18:03:34

interesting

thheller18:03:36

I was even thinking that fns like this could be automatically elided during release compiles but that would be way harder for you

bhauman18:03:03

yeah I'm moving out of the compile side of things

thheller18:03:38

a "standard" set of metadata tags for this stuff would be nice though

thheller18:03:58

I saw something like :fighwheel-always and things already

bhauman19:03:16

yes it would be nice

thheller19:03:18

do you have hooks for running code before loading any code already? or only :on-jsload?

bhauman19:03:39

yes I have before hooks

bhauman19:03:04

basically before and after, no distinction for async

thheller19:03:41

I added the async due to node. its quite frequent that you need to wait for something to actually finish before continuing, eg. when closing http servers

thheller19:03:38

that frequently failed if I just called (.close srv) and immediately continued with live-reloading

thheller19:03:52

:before-load demo.script/stop in this case but (defn ^:dev/before-load-async stop [done] ...) would be neat

thheller19:03:15

I generally not a fan of having too much config in code but metadata solves this nicely as it doesn't really end up in the code