This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-07-14
Channels
- # aleph (16)
- # bangalore-clj (4)
- # beginners (19)
- # boot (27)
- # cider (81)
- # clara (2)
- # cljs-dev (343)
- # cljsrn (97)
- # clojure (224)
- # clojure-hk (1)
- # clojure-italy (25)
- # clojure-russia (5)
- # clojure-serbia (2)
- # clojure-spec (7)
- # clojure-uk (27)
- # clojurescript (97)
- # cursive (8)
- # datomic (48)
- # docker (1)
- # emacs (15)
- # hoplon (39)
- # jobs (4)
- # lumo (13)
- # off-topic (2)
- # om (66)
- # onyx (7)
- # parinfer (5)
- # pedestal (2)
- # play-clj (10)
- # protorepl (2)
- # quil (1)
- # re-frame (38)
- # reagent (33)
- # spacemacs (1)
- # specter (4)
- # sql (19)
- # test-check (31)
- # unrepl (4)
- # untangled (3)
is there a recommended way how to dynamically insert svg elements using goog.closure only?
hmmm, also, i cannot access attribute types like goog.dom.Attr/REL
… gives me undefined in console
so I'm trying to use a combination of :language-out :es5-strict
, :output-wrapper true
, and in my code I want to judiciously use (goog/exportSymbol ...)
to put something into a global object (`this` inside the wrapper).
but clojurescript output-wraps code like ;(function(){...js...})()
which leaves this
as undefined
in strict mode, causing an error.
is it reasonable to expect to be able to configure the output wrapper template, say to bind an arbitrary value as the wrapper function's this
? or should I not expect to be able to use goog/exportSymbol
in strict mode at all?
I suppose I'd like to generate something like ;(function(){...js...}).bind(...arbitrary_configured_value...)()
if you use a library from cljsjs, does this suggest that it is closure advanced compatible? that is, cljsjs is only wrapping libraries that can be advance compiled?
how does the dependency work, i.e. if i do an advanced compilation and i just get a single app.js, if they are not included in the advanced, then where are they?
i noticed when i build a reagent app, and I see the React js in the app.js, my own machine user account and full path to the project file are actually in this compiled JS file. is this normal?
@dnolen it just comes out of a hello world reframe build, the whole path reflects something in the cljs compiler: (ce,"/Users/andrew/projects/ajs/reframe3/target/cljsbuild-compiler-1/cljs/core.cljc")
I would file an issue with them first, and maybe it will it turn out to be something we need to addresss
i'll try some other builds without reframe and see if i see similar. i saw this a few years ago on the Om Previous builds as well
is cljs.core/destructure
supposed to work under self-host? Planck gives me “Use of undeclared Var cljs.core/destructure” even though I can (doc cljs.core/destructure)
Probably an abuse but you can do this in either Lumo or Planck: (cljs.core$macros/destructure '[[a b] [1 2]])
If you can write macros using cljs.core/destructure
in JVM ClojureScript, but not write macros using it in self-hosted, then that would be a self-hosted bug
does this count: https://github.com/hoplon/javelin/blob/master/src/javelin/core.clj#L29 ? It’s a Cljs library
@dm3 On the surface that usage should be fine. I think there is a resolver bug that has come up so infrequently, that we have just worked around it like this https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/spec/test/alpha.cljc#L107-L108
@dm3 So, your workaround would be to use reader conditionals and refer to cljs.core$macros/destructure
if the macros namespace is being compiled as ClojureScript code.
Feel free to write a JIRA. (I suspect that the resolver code might be able to be revised to handle that exact situation.)
@dnolen it looks like a vanila reagent build does not leak this metadata, so it must be a fundamental issue with re-frame. i will address an issue
@mfikes: another interesting case. I have a macro-only file, all functions/macros wrapped with net.cgrand.macrovich/deftime
. There’s a function bind-syms
which is used from two macros below it.
bind-syms
: https://github.com/dm3/javelin/blob/macros-split-clj/src/javelin/macros.cljc#L30
callsite #1: https://github.com/dm3/javelin/blob/macros-split-clj/src/javelin/macros.cljc#L137
callsite #2: https://github.com/dm3/javelin/blob/macros-split-clj/src/javelin/macros.cljc#L208
When loaded in Planck, and require-macros
the ns I get an error only for the second callsite:
planck -c src/:macrovich-0.2.0.jar
cljs.user=> (require-macros '[javelin.macros :as m])
WARNING: Use of undeclared Var javelin.macros$macros/bind-syms at line 208 /Users/dm3/projects/dm3/javelin/src/javelin/macros.cljc
@dm3 You might be seeing CLJS-2101, which was fixed in 1.9.655. If you really wanted, you could build Planck against ClojureScript master to see if that’s what you are seeing.
@dnolen i know you are interested in the continuing saga of this metadata leakage; it is not re-frame either, it is only with a dependency on re-frisk
Is the isa?
function supposed to go up the prototype chain, like instanceof
? The doc seems to imply it does, but I gave it an instance of a class that extends Map, and it said false. (It also said false with a plain object and Object as parent.)
(A JS class, that is.)
@mfikes another thing I noted but don’t have time to investigate right now - in JVM Clojurescript I can store metadata on symbols when walking code in macros. Can’t do that under self-host. Example exactly on the line at this URL: https://github.com/dm3/javelin/commit/e833b34ef4df9c2b8db88df80bde73ceb6607ea8#diff-642dffb125639fc57f0ee5bc98aa9c77L101
Actually, it looks like instance?
is more what I'm looking for
@dm3 That’s interesting. You can certainly have meta on symbols in self-host. Perhaps some odd interaction when processing macro code.
is it a common practice in clojurescript to use the (goog.*)
functions directly?
or is that more of a compiler detail?
yeah I would assume you'd have to require them in. I'm reading more about it here: https://clojurescript.org/guides/quick-start#google-closure-library
I think I might just need to sit down and actually go through the entire "Quick Start" guide to get a feel for how everything works together.
I like the expressivity of Clojure's data structures, the fact that code is just data, and immutability by default. But I'm already basically only doing functional programming using pure JS (I use ES6 arrow functions, object rest spread to never mutate objects in place, etc), so I'm trying to figure out exactly what ClojureScript buys me over just staying with native JS.
@chrisbroome The libraries are often paradigm changing in cljs, I.e. Reframe, that's one reason to consider the language. Of course, they're also the language specific features. But there are some interesting approaches to solving common industrywide challenges in user interface development that have solutions in cljs
Technically, you could use it in JS
yeah I think I really just need to play with it more
I'm trying to get my employer to pay for tickets to clojure/conj in baltimore. i live in the DC area, so it's not like I'd need to stay in a hotel lol
CLJS also lets you take advantage of the benefits of Google Closure without having to write weird JavaScript.
object spread et al do not really 'solve' the mutability issue in js, i have a lot of experience with nested object spreads because we use redux. its not pretty
yeah I'm just not that familiar with Google Closure. I've mainly used babel/webpack for compilation
yeah I completely agree @samcf
it's more of a convention and try not to shoot yourself in the foot
@chrisbroome it’s really just a very different language - I’ve been writing JS for 12 years (still do), but I’d rather write Clojure
unlike some people, I don’t really find JS all that distasteful - but it’s no longer the most productive tool for me
yeah that's probably how I should look at it. I immediately saw the value prop for using Clojure since you can leverage the existing JVM libraries if you need them, but you don't want to actually write Java code. I actually really like that idea because I've never been a huge Java fan (but oddly enough I did like C# for the few years that I used it).
so I should probably just approach ClojureScript that way also
thanks for answering my noob questions everyone
@chrisbroome for example, I think most would agree that the syntax and use of react is significantly improved in cljs.
@chrisbroome if you are exploring the compile-to-js space it's fair to consider other languages as well, get a well rounded idea of where the industry is at.
I recently put myself through a 2-week boot camp with Elm to see what it's about. It also has some attractive trade-offs compared to writing raw JavaScript
I explored Elm a while back because I actually like the Haskell/ML-style "syntax". It was decent
Every solution has its own strengths and drawbacks, it's worth trying different things and seeing what fits your style
@ajs we’re quite friendly with the maintainers of Elm at least - there’s been more than little cross-pollination of ideas between our communities
There are definitely some similarities between reframe and the Elm architecture. One is more flexible, one is easier.
I know redux was at least somewhat modeled off the elm architecture
Some of the older idioms from two or three years ago in Om were where I first used those architectural ideas. The older Om in combination with a global core.async channel gave you something very similar to the Elm architecture
random question: transducers are a more-performant seq transform because they dont create intermediates… but i’m curious about the specific cljs implementation. does the same statement hold true for js? (basically, if I found hotspots in my code relating to large data xforms, would converting to transducers make a difference?)
@dnolen not sure if this is interesting to you or not, but the metadata leak is due to a particular dependency on cljs.js : https://github.com/flexsurfer/re-frisk/issues/38#issuecomment-315444613
not sure why he would include the cljs runtime compiler if it doesn't add any functionality, as he notes in the recent comment.
i wonder if that's why a simple hello world build of a re-frisk program in advanced compilation takes 200 seconds on a brand new 4-core mac, compared to 14 seconds without the re-frisk
my understanding is that both versions of Om share the namespaces om.core and om.div and thus you can use the current version of Om even if you are not using the Next features, is that right? does this mean that a codebase using an older version of Om should be able to seamlessly upgrade to the current version?