Fork me on GitHub
#clojurescript
<
2017-07-14
>
michael.heuberger01:07:47

is there a recommended way how to dynamically insert svg elements using goog.closure only?

michael.heuberger03:07:55

hmmm, also, i cannot access attribute types like goog.dom.Attr/REL … gives me undefined in console

arbscht06:07:17

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?

arbscht06:07:39

I suppose I'd like to generate something like ;(function(){...js...}).bind(...arbitrary_configured_value...)()

ajs11:07:10

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?

thheller11:07:23

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

ajs11:07:03

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?

thheller11:07:36

prepended into the file AFTER :advanced compilation

ajs11:07:03

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?

ajs11:07:28

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

dnolen12:07:02

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

ajs12:07:05

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

dnolen12:07:21

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

dnolen12:07:10

I would file an issue with them first, and maybe it will it turn out to be something we need to addresss

ajs12:07:36

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

dm312:07:25

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)

dnolen12:07:14

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

dnolen12:07:29

unless your writing macros that want destructuring support

dm312:07:58

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

mfikes12:07:29

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

dm312:07:12

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

dm312:07:26

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

mfikes12:07:24

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

mfikes12:07:38

@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

mfikes12:07:43

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

dm312:07:55

yep, did that right now, thanks! 🙂

mfikes12:07:56

Not ideal, but I suspect that would work.

dm312:07:22

it does. Have other unrelated problems though 🙂

mfikes12:07:52

Feel free to write a JIRA. (I suspect that the resolver code might be able to be revised to handle that exact situation.)

ajs12:07:26

@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

dm312:07:59

@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

mfikes13:07:06

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

mfikes13:07:50

IIRC, that bug is just a warning you can ignore

ajs13:07:49

@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

ajs13:07:18

issues have been filed

dnolen13:07:20

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

ajs13:07:57

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

ajs13:07:01

get a beer

dnolen13:07:11

heh, I wish

tech_hutch14:07:02

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

tech_hutch14:07:29

(A JS class, that is.)

dm314:07:10

@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

tech_hutch14:07:11

Actually, it looks like instance? is more what I'm looking for

mfikes14:07:05

@dm3 That’s interesting. You can certainly have meta on symbols in self-host. Perhaps some odd interaction when processing macro code.

chrisbroome15:07:53

is it a common practice in clojurescript to use the (goog.*) functions directly?

chrisbroome15:07:12

or is that more of a compiler detail?

dnolen15:07:31

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

dnolen15:07:38

explicit require is alway recommended

chrisbroome15:07:27

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

chrisbroome15:07:43

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.

chrisbroome15:07:29

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.

ajs15:07:11

@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

samcf15:07:54

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

tech_hutch15:07:21

Technically, you could use it in JS

chrisbroome15:07:23

yeah I think I really just need to play with it more

chrisbroome15:07:28

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

tech_hutch15:07:11

CLJS also lets you take advantage of the benefits of Google Closure without having to write weird JavaScript.

samcf15:07:01

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

chrisbroome15:07:05

yeah I'm just not that familiar with Google Closure. I've mainly used babel/webpack for compilation

chrisbroome15:07:31

yeah I completely agree @samcf

chrisbroome15:07:44

it's more of a convention and try not to shoot yourself in the foot

dnolen15:07:17

@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

dnolen15:07:46

unlike some people, I don’t really find JS all that distasteful - but it’s no longer the most productive tool for me

chrisbroome15:07:46

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

samcf15:07:22

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

chrisbroome15:07:23

so I should probably just approach ClojureScript that way also

chrisbroome16:07:35

thanks for answering my noob questions everyone

ajs16:07:11

@chrisbroome for example, I think most would agree that the syntax and use of react is significantly improved in cljs.

ajs16:07:11

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

samcf16:07:25

i've been tempted to take a stab at that ocaml->js thing that facebook made

ajs16:07:39

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

chrisbroome16:07:09

I explored Elm a while back because I actually like the Haskell/ML-style "syntax". It was decent

ajs16:07:16

Every solution has its own strengths and drawbacks, it's worth trying different things and seeing what fits your style

ajs16:07:54

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

dnolen16:07:43

@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

ajs16:07:28

@dnolen that's good to hear.

ajs16:07:02

There are definitely some similarities between reframe and the Elm architecture. One is more flexible, one is easier.

chrisbroome16:07:35

I know redux was at least somewhat modeled off the elm architecture

ajs16:07:18

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

lwhorton17:07:21

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

dnolen18:07:28

Implementation is same as Clojure

ajs19:07:26

@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

dnolen19:07:47

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

ajs19:07:43

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

dnolen19:07:20

your guess is as good as mine

dnolen19:07:34

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

ajs19:07:08

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

dnolen19:07:06

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

ajs21:07:38

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?