This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-12-11
Channels
- # adventofcode (129)
- # architecture (10)
- # beginners (163)
- # boot (1)
- # cider (34)
- # cljs-dev (9)
- # clojure (210)
- # clojure-austin (11)
- # clojure-czech (2)
- # clojure-gamedev (1)
- # clojure-greece (67)
- # clojure-italy (2)
- # clojure-russia (8)
- # clojure-spec (36)
- # clojure-uk (54)
- # clojurescript (87)
- # cursive (12)
- # data-science (6)
- # datomic (13)
- # devcards (4)
- # editors (2)
- # emacs (34)
- # figwheel (6)
- # fulcro (147)
- # graphql (17)
- # lumo (54)
- # off-topic (37)
- # om (11)
- # onyx (7)
- # parinfer (10)
- # random (1)
- # re-frame (13)
- # ring (10)
- # ring-swagger (2)
- # sfcljs (1)
- # shadow-cljs (1)
- # spacemacs (32)
- # test-check (4)
- # unrepl (84)
@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
Yeah, I often find myself inspecting the generated JavaScript to ensure proper interop.
Currently trying to "inherit" a controller from another controller, which I understand boils down to Child.prototype = Object.create(Parent.prototype);
Do any libraries make it possible to run test coverage on clojurescript?
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.
@bravilogy which section in that page?
I followed the example under JavaScript Modules section and tried to implement it in my existing chestnut template
@bravilogy is your cljs version up to date in chestnut?
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
@bravilogy see the cljsjs project
@bravilogy I made a small demo app a while ago: https://github.com/fbielejec/npm-deps-demo
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)
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]))
@bravilogy You might want to check out: https://github.com/thheller/shadow-cljs
If you mean if it does hot-reload, yes it does
@bravilogy you cannot just add a dep and immediately require it, you must restart your build process or Figwheel or whatever
shadow-cljs is not really a Figwheel replacement, Figwheel does of lot of stuff these days
rewinding a bit, shadow-cljs might be what you want if you want to use Webpack to manage your JS deps
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
@mitchelkuijpers I don’t see how it could do everything that Figwheel does simply in terms of length of development and usage
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
but I could be wrong, but your claim would be the first I’ve heard that that’s the case
(I’m not talking about shadow-cljs in general, just the hot-reloading development experience, configurability)
it’s also still hard to make a comparison without trying it and asking lots of questions due to lack of docs?
@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
But it definitely not as battle tested as figwheel ^^
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
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.
You don't even need leiningen for it 😉
But point taken, I should just write some awesome docs then
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?
@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.
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"
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.
I'm trying to sneak it into a grafana plugin, but grafana (an angular 1.6 app) barfs because something bad happens to <body>
are you trying to use a react lib that might be rendering into body automatically?
nope, I'm effectively building a blob of JS that Grafana picks up as a module, no deps whatsoever
but figwheel does run this 'ensure-container' method that barfs because it claims there is no body
oh right, the HUD needs a body to attach to right?
right, and there's definitely a body on the page, but I think it might be interacting in a weird way
Does anyone else have a problem with emacs becoming very sluggish when running a Clojurescript REPL with figwheel?
I wouldn’t find that surprising, it’s easy to do async wrong in elisp
and that’s if they are even trying to do things async
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?
not familiar with prelude, but if there's any syntax checking or linting or whatever, that's often what kills editor performance
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
There is this issue related to searching https://github.com/syl20bnr/spacemacs/issues/9220
It actually points back to spaceline (powerline) modeline in spacemacs. Not sure if that is relevant to your setup with prelude
was never a problem with clojure but once I had both clojure and clojurescript REPLs running it ran like a dog
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.
@mac they should be JS doubles: https://clojurescript.org/about/differences#_data_structures
@briantrice Thanks for the tip.
seems like cljs compiler with :optimizations :none
will emit document.write
to load all the stuff
in shadow-cljs build config you can specify :devtools {:async-require true}
which won’t use document.write
to load files.
however this blows away the page in my case, because in my case document
has already been closed