This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-08-10
Channels
- # aleph (3)
- # architecture (3)
- # bangalore-clj (5)
- # beginners (75)
- # boot (75)
- # cider (2)
- # cljs-dev (48)
- # cljsjs (3)
- # cljsrn (17)
- # clojure (125)
- # clojure-belgium (1)
- # clojure-boston (1)
- # clojure-italy (20)
- # clojure-losangeles (2)
- # clojure-spec (73)
- # clojure-uk (34)
- # clojurescript (127)
- # cursive (8)
- # data-science (5)
- # datascript (128)
- # datomic (5)
- # emacs (4)
- # events (3)
- # fulcro (1)
- # jobs (1)
- # jobs-discuss (4)
- # jobs-rus (9)
- # keechma (79)
- # lein-figwheel (2)
- # leiningen (2)
- # lumo (31)
- # om (1)
- # parinfer (61)
- # pedestal (1)
- # planck (1)
- # portkey (31)
- # re-frame (34)
- # reagent (53)
- # ring (3)
- # ring-swagger (13)
- # rum (1)
- # spacemacs (14)
- # testing (1)
- # yada (2)
@lvh so I can’t repro with current master
FWIW as a workaround (def Logging (js/require "@google-cloud/logging"))
seems to work fine
with :target :nodejs
right, that would work
but I just tried in an example project and could compile & run
(ns foo.core
(:require ["@google-cloud/logging" :as gl]))
(enable-console-print!)
(println "google logging:" gl)
@lvh would be helpful to know which CLJS version/revision + compiler opts?
you sure you have :target :nodejs
in there? 🙂
because there seems to be a bug when compiling for web
watch.clj:
(require '[cljs.build.api :as b])
(b/watch
"src"
{:output-to "main.js"
:output-dir "out"
:main 'cspshovel.core
:target :nodejs
;;
:process-shim false
:optimizations :simple
:npm-deps {:csp-report-norm "0.1.0"
:aws-elasticsearch-client "1.0.2"
"@google-cloud/logging" "1.0.5"}
:install-deps true
:verbose true})
please try master
@lvh this is your problem https://github.com/clojure/clojurescript/commit/c1aa91ca6188e9344e71f46e426bc004c6f197cd
git clone
then note down the CLJS version it built
and use that in your dependencies
not sure about checkouts
@lvh let me know if that fixes it
I think there’s a release going out tomorrow
but I don’t cut releases so not promising anything 🙂
@anmonteiro that did indeed fix it! thanks 🙂
Hey everyone,
Anyone seen this before when interoping with a js-object?
In the repl I can call:
(.-get.user_email js/gmail)
which gives me:
#object[Function "function () {
return api.tracker.globals[10];
}"]
However trying to log out the same function to js/console just gives me undefined, even though js-keys
shows the name "user_email"
and logging the result of .-get
has the function appearing.@lvh an immediate workaround is to query for @google-cloud/logging/src
we just couldn’t compute the provided main 😛
@anmonteiro huh? I meant doing js/require
🙂
I mean putting what I said and using the namespace declaration
there’s an extra /src
in there
@lvh the reason stuff like "react-dom/server"
works is because we index the node_modules
installation
the above actually means there’s a node_modules/react-dom/server.js
file
conj talk suggestion (which I’m sure was submitted): step-by-step walkthrough of what happens when you $FANCY_CLJS_FEATURE
CFP is over
but I did submit a talk on this 🙂
anyway, to continue what I was explaining
if in your case you have @google-cloud/logging/src/index.js
we index that as ["@google-cloud/logging/src/index.js", "@google-cloud/logging/src/index", "@google-cloud/logging/src"]
^ so you can require for any of the above
plus, if it’s the specified "main"
in package.json
, we also index it as "@google-cloud/logging"
in this case
but in your case there’s a bug preventing it from happening
which has been fixed in the meantime
can’t seem to get Domina to fire scroll events for the browser window, what am I missing?
(ns keyboard.views
(:require [re-frame.core :as rf]
[re-com.core :as rc]
[domina :as dom]
[domina.css :as css]
[domina.events :as events]))
;; home
(events/unlisten!)
(events/listen! :keydown #(rf/dispatch [:add-down %]))
(events/listen! :keyup #(rf/dispatch [:remove-down %]))
(events/listen! (css/sel "html") :scroll #(rf/dispatch [:handle-scroll]))
also tried (css/sel "body")
and (events/listen! :scroll #(rf/dispatch [:handle-scroll]))
Hello CLJS people. Is there a way, with the CLJS repo, to simply reinstall the CLJS jar locally anytime a change is made in source code ? I want to explore CLJS through my app.
@djebbz hrm I don’t think so. Seems like you might want to use Lein checkouts? https://github.com/technomancy/leiningen/blob/master/doc/TUTORIAL.md#checkout-dependencies
I want this, but my project is using boot
, so I need the watch and rebuild capability independently.
how are most people doing data vis in Cljs? Just binding to D3?
@grounded_sage I’m not using this, but this looks highly interesting https://github.com/thi-ng/geom/blob/master/geom-viz/src/core.org
Thanks I did come across that but given that it is Beta I'm not sure I'm keen to dive into it. I ended up deciding I'm going to play around with Elm Plot
@grounded_sage it’s a popular option yes
@dsapoetra it seems like you are using b
for generating a list of items (therefore it seems to assume you have a list in it). Then after you try to get an :id
out of it as well. So you probably don't have a list in there?
@richiardiandrea I forgot
a -> {“id” {:score integer}}
b -> [{:id “id”} {“:id “id”}]
So, a
is map, b
is vector of map
If I omit foo
definition from defrecord
body it works correctly
also, changing (bar this 2)
to (apply bar [this 2])
or even ((identity bar) this 2)
works correctly
Just read this from https://reasonml.github.io/guide/javascript/converting: >We highly recommend you to check the JS output into version control. It makes your build system integration quasi-nonexistent, and makes sure that when you’re not there, your teammates can make small changes, audit the output diff, and catch any mistakes. It’s also a great selling point that the checked in JS output is friendly to emergency hot patches (a big selling point for managers!). Even if you’re upgrading BuckleScript version, you’d catch any output difference. It’s like Jest snapshots, for free!
I'd say if you have to look at the .js output of CLJS you need to refine your dev workflow
so I'd say no
it looks like reason prioritizes simple /readable js output, which is cool I guess but not what every lang using js as a target is doing
CLJS does so many optimizations the resulting .js is rather meaningless for humans unless you really know what you're doing.
@grav that recommendation exists mostly because JS compiled from Reason needs additional build steps in order to produce the final artifact
ClojureScript has an all-encompassing solution with the Closure Compiler
@anmonteiro it still doesn’t sound like a great recommendation
oh no
not sure that’s what they mean
wait, that’s exactly what they mean
that’s directed at teams that have 1 person doing Reason and others doing JS
their message is strongly directed at converting JS codebases to reason
yeah, well, I’ve been doing some Reason on the side recently and haven’t checked in any JS
kinda agree that recommendation shouldn’t be such a highlight 😛
I dunno, I recall people recommending this with CoffeeScript, and having tried it - don’t recall any benefits
We were committing dist
in Typescript here, and it was so so so annoying that we got rid of that
It’s surprising that you can efficiently implement your language’s semantics by transpiling to another language while simultaneously keeping the output human-readable, even if downstream tooling operates on that intermediate result.
not to mention that committing js bundles to git is not sustainable in the long run - git is not built to contain (lots of) build artifacts
@mfikes probably easier if you know exactly what the types are
less so in a dynamically typed language like CLJS where emitting performant code is more difficult
well Reason's output is super good and commented even, so it was the only one worth committing
(yeah exactly because of types)
@richiardiandrea CoffeeScript had the exact same story
Even, that, consider the old Cfront
, where types where known: What if it tried to generate idiomatic C? Seems challenging.
@mfikes different kind of typing
@dnolen coming from CLJS, I was very surprised when I discovered that in the Typescript/JS world the REPL is not used at all (...plus the horrible .editor
mode) and some folks only have two windows on the screen: one with the source and the other with the transpiled code. I have never understood the utility of that...actually I would like to know if I am missing something 😄
@dnolen is this something that should be reported as a bug or am I doing something wrong? https://clojurians.slack.com/archives/C03S1L9DN/p1502385182089351 I couldn't find any mentions of behavior change in the change log and it seems that it was introduced in 1.9.456
@mihaelkonjevic I can’t get your approach to work in Clojure (replacing default
with Object
). It seems you want to be able to partially implement a protocol, and have it fall back for the parts not implemented. Interesting.
Yeah, that's how I'm using it. The interesting thing is that it's breaking only if the non overriden method is called from inside of the overriden method
@mihaelkonjevic If you try it in Clojure, you’ll see that once you partially implement Test
in TestR
, you can no longer (bar (->TestR) 1)
@mfikes What's the reason for that though? Isn't it useful for methods to fall back on the default implementation?
@urbank I’m just being lazy and using Clojure’s implementation as the definition of how protocols are supposed to work when partially implemented.
Hmm. @mihaelkonjevic that doesn’t work in Clojure. Perhaps the fact that the above works is an accident of implmentation.
@mihaelkonjevic you shouldn’t have ever expected that to work, if it did purely accidental
@richiardiandrea heh yeah, not surprised re: TypeScript, and yeah in JS people really don’t lean on the REPL because the integration isn’t that good and many coding patterns make it less useful
@dnolen thanks, good to know