Fork me on GitHub

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?


@ajs the opposite, nothing from cljsjs will go through :advanced


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?


prepended into the file AFTER :advanced compilation


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?


for example, things like this: mc(ce,"/Users/andrew/projects/ajs/...


@ajs that’s possible if something is generating metadata yes


@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")


@ajs I don’t know that much about reframe so I can’t say why that is happening


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)


@dm3 that’s not actually a thing to use directly


unless your writing macros that want destructuring support


yeah, I was trying to use it in a function within a macro


Probably an abuse but you can do this in either Lumo or Planck: (cljs.core$macros/destructure '[[a b] [1 2]])


ah, so it’s a “def-time” function which is only in the special ns


how self-host works is still a mystery to me 🙂


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


@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


@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.


yep, did that right now, thanks! 🙂


Not ideal, but I suspect that would work.


it does. Have other unrelated problems though 🙂


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: callsite #1: callsite #2: 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.


IIRC, that bug is just a warning you can ignore


@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


issues have been filed


@ajs as long as it’s not in ClojureScript that’s all I’m really concerned about 🙂


@dnolen you can have the morning off, this problem is not on you


get a beer


heh, I wish


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:


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?


you shouldn’t do that, only a few are implicitly loaded by the standard lib


explicit require is alway recommended


yeah I would assume you'd have to require them in. I'm reading more about it here:


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


i yearn for the clojure std lib when i work on js projects at work


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).


maybe i can convince my coworkers to import mori or immutablejs >_>


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've been tempted to take a stab at that ocaml->js thing that facebook made


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


Just don't mention clojurescript when you talk to the Elm Folks :)


@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


@dnolen that's good to hear.


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?)


Implementation is same as Clojure


@dnolen not sure if this is interesting to you or not, but the metadata leak is due to a particular dependency on cljs.js :


@ajs that’s just not enough information for me to consider anything - but thanks


not sure why he would include the cljs runtime compiler if it doesn't add any functionality, as he notes in the recent comment.


your guess is as good as mine


nobody should be requiring cljs.js w/o a really, really good reason


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


@ajs cljs.js doesn’t even work with advanced compilation


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?