Fork me on GitHub
#clojurescript
<
2017-12-11
>
hagmonk00:12:26

@mfikes for the record, I'm trying to build a Grafana plugin using CLJS, bit out of my JS interop depth ... so I'm down to wanting to manually inspect the generated JS to try to make it match what Grafana / Angular JS expect

mfikes00:12:11

Yeah, I often find myself inspecting the generated JavaScript to ensure proper interop.

hagmonk00:12:47

Currently trying to "inherit" a controller from another controller, which I understand boils down to Child.prototype = Object.create(Parent.prototype);

hagmonk00:12:27

My there-has-to-be-a-better-way spider sense is off the charts

caleb.macdonaldblack01:12:38

Do any libraries make it possible to run test coverage on clojurescript?

amit588105:12:00

how to add image inside :div?

qqq06:12:56

img tag with src field

Bravi10:12:23

can anyone give me a quick example how to use npm modules in cljs please?

Bravi10:12:55

when I follow the official docs on https://clojurescript.org/guides/javascript-modules I get

Caused by: java.io.FileNotFoundException: Could not locate js/hello__init.class or js/hello.clj on classpath.

dominicm10:12:31

@bravilogy which section in that page?

Bravi10:12:24

JavaScript Modules

Bravi10:12:33

didn’t understand the question 😕

Bravi10:12:16

I followed the example under JavaScript Modules section and tried to implement it in my existing chestnut template

dominicm10:12:39

@bravilogy is your cljs version up to date in chestnut?

Bravi10:12:12

I’m using 1.9.671

Bravi10:12:50

it came with chestnut by default. I should I change it to 1.9.854 instead?

Bravi10:12:05

nah still the same

dominicm10:12:45

I think 854 is the minimum required for this feature

dominicm10:12:03

I remember reporting a bug that an older version didn't work in fact.

Bravi10:12:32

what other alternatives do I have to use npm packages? I was thinking to set up webpack and then expose a bunch of global js functions there and load the compiled output before my cljs app

dominicm10:12:42

@bravilogy see the cljsjs project

fbielejec11:12:10

but in my experience it doesn't survive production compilation, even with externs, but didn't have time to go into this deeper (it was easier to package for cljsjs)

Bravi11:12:36

tried to add cljsjs.moment and I get this:

No such namespace: cljsjs.moment, could not locate cljsjs/moment.cljs
😞 my dependencies:
:dependencies [[org.clojure/clojure "1.8.0"]
                 [org.clojure/clojurescript "1.9.854" :scope "provided"]
                 [com.cognitect/transit-clj "0.8.300"]
                 [ring "1.6.2"]
                 [ring/ring-defaults "0.3.1"]
                 [bk/ring-gzip "0.2.1"]
                 [radicalzephyr/ring.middleware.logger "0.6.0"]
                 [compojure "1.6.0"]
                 [environ "1.1.0"]
                 [com.stuartsierra/component "0.3.2"]
                 [org.danielsz/system "0.4.0"]
                 [org.clojure/tools.namespace "0.2.11"]
                 [org.omcljs/om "1.0.0-alpha48"]
                 [clj-http "3.7.0"]
                 [hiccup "2.0.0-alpha1"]
                 [cheshire "5.8.0"]
                 [cljsjs/moment "2.17.1-1"]]
and this is how I’m requiring it:
...
  (:require [cljsjs.moment]))

Bravi11:12:59

is this figwheel replacement?

mitchelkuijpers12:12:20

If you mean if it does hot-reload, yes it does

dnolen13:12:58

@bravilogy you cannot just add a dep and immediately require it, you must restart your build process or Figwheel or whatever

dnolen13:12:19

shadow-cljs is not really a Figwheel replacement, Figwheel does of lot of stuff these days

dnolen13:12:01

rewinding a bit, shadow-cljs might be what you want if you want to use Webpack to manage your JS deps

mitchelkuijpers13:12:55

It does everything Figwheel does and more. And you don't need webpack you just npm-install and require a dep and it will just work

dnolen14:12:20

@mitchelkuijpers I don’t see how it could do everything that Figwheel does simply in terms of length of development and usage

dnolen14:12:23

it may do the hot-loading bit, and maybe that’s all that’s desired, but I seriously doubt it is as far a long for that usecase as Figwheel

dnolen14:12:36

but I could be wrong, but your claim would be the first I’ve heard that that’s the case

dnolen14:12:20

(I’m not talking about shadow-cljs in general, just the hot-reloading development experience, configurability)

dnolen14:12:38

it’s also still hard to make a comparison without trying it and asking lots of questions due to lack of docs?

mitchelkuijpers14:12:17

@dnolen Docs are definitely a problem that theller is wel aware off. But it gives you hot-reloading with great error messages it is pretty easy to try with: https://github.com/thheller/shadow-cljs/wiki/ClojureScript-for-the-browser and I think the readme is also pretty nice: https://github.com/thheller/shadow-cljs . And the npm integration is pretty slick it does simple optimizations on your npm-depencies and then advanced compilation on the cljs output. And somehow I never wrote externs and it all works

mitchelkuijpers14:12:06

But it definitely not as battle tested as figwheel ^^

dnolen14:12:18

ok cool that’s good to hear - but I think directing people toward tooling with less docs doesn’t necessarily seem productive for newcomers is all

Jon04:12:19

shadow-cljs has changed a lot in the past year, adding CommonJS support first, then lots of improvements on hot code swapping, prettier error messages, CLI usage, code bundling, REPL support. almost all I need to debug and release ClojureScript based websites.

dnolen14:12:27

I need to give shadow-cljs a proper spin soon

mitchelkuijpers14:12:52

You don't even need leiningen for it 😉

dnolen14:12:12

you don’t need to tell me

dnolen14:12:16

I only use Maven

mitchelkuijpers14:12:25

But point taken, I should just write some awesome docs then

dnolen14:12:32

but this not a path I would recommend when starting out

vemv15:12:51

any reason why Error.prepareStackTrace is undefined in Chrome?

vemv15:12:03

(it's in fact Chrome-specific)

rkiouak17:12:05

Hi-- beginner question with om.next-- I have a sample/toy app using om.next on the front end with transact, query, etc. working running through the reconciler. I'm now wondering how I can replicate the react behavior of local state in a component via this.setState ({...})-- e.g. a transact! seems both unnecessary and undesirable as no other component will need to track this state. When I try (om/set-state! this {:startDate "01/01/2018"}), i get a "No queries exist for component path ..." with my core/reconciler comp and the component i'm trying to set state on, and its not clear to me what i'm doing wrong. Anyone around and willing to help me understand how to do this?

dnolen17:12:49

@mrkiouak there’s an #om channel

hagmonk18:12:29

@dnolen strangely, in some ways "less docs" can actually help. When looking at shadow-cljs the readme had a link for "Compiling node.js libraries" and suddenly I was off to the races. It was terse but the example given worked out of the box.

hagmonk18:12:55

Maybe that speaks more to the benefit of "task oriented" documentation, which I think really appeals to newcomers. "Here's how you do familiar thing X in unfamiliar environment Y"

dnolen18:12:16

guides are important of course, but you also need plain old reference docs too

hagmonk18:12:10

Totally, my next step was basically "read the source code", haha. But the pithy example got me believing this tool could do what I was after.

hagmonk18:12:31

"could do what I was after" I think I need more coffee

hagmonk21:12:06

has anyone here seen figwheel cause problems with the body tag of a page?

hagmonk21:12:32

I'm trying to sneak it into a grafana plugin, but grafana (an angular 1.6 app) barfs because something bad happens to <body>

noisesmith21:12:48

are you trying to use a react lib that might be rendering into body automatically?

hagmonk21:12:22

nope, I'm effectively building a blob of JS that Grafana picks up as a module, no deps whatsoever

hagmonk21:12:51

but figwheel does run this 'ensure-container' method that barfs because it claims there is no body

hagmonk21:12:16

disabling the HUD makes that problem go away, but angular.js gets angry regardless

noisesmith21:12:54

oh right, the HUD needs a body to attach to right?

hagmonk21:12:35

right, and there's definitely a body on the page, but I think it might be interacting in a weird way

hagmonk21:12:45

since this code is being brought in dynamically as a module

sofra21:12:31

Does anyone else have a problem with emacs becoming very sluggish when running a Clojurescript REPL with figwheel?

noisesmith21:12:36

I wouldn’t find that surprising, it’s easy to do async wrong in elisp

noisesmith21:12:51

and that’s if they are even trying to do things async

sofra22:12:06

hmm, surely lots of people would have this problem. I am using it in the very standard way C-c M-J ... maybe I have something else in my setup slowing things down?

hagmonk22:12:44

are you using spacemacs?

sofra22:12:46

would consider switching if that turned out to be an issue

hagmonk22:12:51

not familiar with prelude, but if there's any syntax checking or linting or whatever, that's often what kills editor performance

hagmonk22:12:35

You could try spinning up a spacemacs session just to isolate the problem, if it's also an issue in spacemacs that says it might be your project's config or elsewhere

sofra22:12:58

that is not a bad idea, thanks!

hagmonk22:12:19

np, good luck

mahinshaw22:12:35

It actually points back to spaceline (powerline) modeline in spacemacs. Not sure if that is relevant to your setup with prelude

sofra23:12:26

cheers all, I turned of aggressive indent and things seem a lot smoother so far

sofra23:12:08

was never a problem with clojure but once I had both clojure and clojurescript REPLs running it ran like a dog

mac23:12:22

I have reimplemented a javascript algorithm that calculate planetary positions in cljs but after a few iterations I am seeing some drift from the original in cljs results. Does cljs per default use the same precision for float operations as javascript or is there a way to force this to rule rounding out as a source of the error.

mac23:12:52

@briantrice Thanks for the tip.

hagmonk23:12:37

seems like cljs compiler with :optimizations :none will emit document.write to load all the stuff

thheller10:12:01

in shadow-cljs build config you can specify :devtools {:async-require true} which won’t use document.write to load files.

hagmonk23:12:16

however this blows away the page in my case, because in my case document has already been closed

Jon04:12:19

shadow-cljs has changed a lot in the past year, adding CommonJS support first, then lots of improvements on hot code swapping, prettier error messages, CLI usage, code bundling, REPL support. almost all I need to debug and release ClojureScript based websites.