Fork me on GitHub
#shadow-cljs
<
2018-09-18
>
wilkerlucio03:09:01

hello, I wrote some JS code that uses ES6 destructuring (like const {a, b} = someObject)

wilkerlucio03:09:24

it works fine on dev, but when I do a production build this doens't work, when I log a or b they come undefined

wilkerlucio03:09:37

how can I make so the compilation works right for this case?

wilkerlucio03:09:24

actually, it seems to understand the destructuring, but the JS is mangling the variable names

wilkerlucio03:09:14

this code:

const {svg, svgWidth, svgHeight, data} = settings

wilkerlucio03:09:29

is getting this JS output:

a = c.svg;
        var d = ;
        b = c.uk;
        var e = c.data;

wilkerlucio03:09:03

c.svg and c.data are correct, but was supposed to be c.svgWidth and c.uk would be c.svgHeight

lwhorton03:09:12

the compiler mangles every single variable name unless told otherwise. when interfacing between the two environments you must be careful to either annotate the name or use a non-mangled accessor. my favorite is https://github.com/binaryage/cljs-oops

wilkerlucio03:09:44

thanks @lwhorton, but I think I'm on a different space here, this is not cljs code, this is js code

lwhorton03:09:59

are you attempting to call the js from cljs?

wilkerlucio03:09:40

yeah, my data gets on JS fine, in my case this is a d3 viz that I wrote on JS, and I require that in a cljs file

wilkerlucio03:09:48

when I call the JS code, my JS object contains the right keys

wilkerlucio03:09:59

but after destructuring the names get bad (see code above)

wilkerlucio03:09:56

kind weird that the names svg and data are correct, but svgWidth and svgHeight are not (got mangled to Am and uk respectively)

lwhorton03:09:42

im not sure i understand how you are invoking the code, but if you are in a compiled cljs file attempting to use javascript source, the cljs (in the optimized js form) will mangle the names, so it’s in effect going from obj.someVar to likely obj.a … but if the js exposes obj.someVar, you will obviously get undefined or null trying to access obj.a.

lwhorton03:09:33

you can avoid this with externs files, or string property accessors (the compiler doesnt mangle strings in any case, so obj["someVar"] will never change), or use the newer ^js typehint

wilkerlucio03:09:42

my invocation is correct, I tried logging the data, as here:

wilkerlucio03:09:44

export function renderPathomTrace(element, settingsSource) {
  const settings = initTrace(element, settingsSource)
  const {svg, svgWidth, svgHeight, data} = settings

  console.log("set svg", svgWidth, svgHeight);

wilkerlucio03:09:07

I know I cna go around using obj["Something"] but then I lose the destructuring properties and have to write a whole lot more

wilkerlucio03:09:21

this is kind looking like a bug somewhere, because I should be able to destructure that

wilkerlucio03:09:26

this is common ES6 code

wilkerlucio03:09:31

nothing special about it

lwhorton03:09:43

i also have no idea how shadow-cljs handles js->js transpilation (es6/7/8 babel?), if at all, so i don’t think i can help further

wilkerlucio03:09:13

yeah, my guess is that there is some compiler-option that I might change to get this to work properly

wilkerlucio03:09:36

I know :language-in and :language-out, but I tried some combinations without success

wilkerlucio03:09:23

ok, I got working with :language-in and :language-out as :ecmascript-next

wilkerlucio03:09:51

but if someone can clarify if that's the correct way to go, please let me know, I think it's fine in my case because it's a chrome extension, so I can count on a updated JS engine

wilkerlucio03:09:49

thanks for hanging with me on this one @lwhorton

thheller05:09:10

@wilkerlucio the JS code will go through :advanced but there are likely no externs for those names since no externs inference is done for JS code

thheller05:09:56

probably easiest to create a externs/your-build.txt and add svgWidth, svgHeight, svg one line each

thheller05:09:36

try shadow-cljs check your-build

thheller05:09:43

it should warn about those

beders10:09:38

I'm sorry if this is a newbie question, but is it possible to eval some ClojureScript code on the browser console (once I've connected to the server etc.). I find myself jumping back and forth between the REPL (running in IntelliJ) and the Chrome JS console (with CLJS formatting enabled). Would be neat to have it all in one place. How are you working with shadow-cljs and Intellij?

claudiu10:09:50

@beders not sure if this is what you mean. For cursive, shadow-cljs, I connect to remote repl localhost 9000. Then evaluate (shadow/nrepl-select :client_build) this send everything to the browser.

beders10:09:09

yup, I'm doing (shadow/repl :app) to connect. Which works fine

beders10:09:19

however, any js/console.log ends up in the browser console and I got those nicely formatted clj objects in there as well. Would be nice if wouldn't have to go back and forth to see all the output and explore objects interactively. I often then tell Chrome to store an object to a global variable (like temp1) which I then access in the REPL via js/temp1 It's ok, but sometimes it would be quicker if in the browser console, I could just type: shadow.eval('(some clojure-script)');

claudiu10:09:22

Ahh no clue. But why not just display it in the repl ? think that should work

thheller11:09:50

@beders that is not currently possible but will be soon

👍 4
❤️ 4
wilkerlucio12:09:21

@thheller cool, in what folder should externs go? root of the project, source root?

wilkerlucio12:09:34

ok, figured at root

dfcarpenter15:09:35

Any examples of integrating scss into a shadow-cljs project?

richiardiandrea21:09:58

does defspec work in shadow? for some reason I don't see my tests reported...

thheller21:09:35

currently they are not discovered properly no

thheller22:09:11

custom runner with normal cljs.test would work

richiardiandrea22:09:27

yep, I think I saw it working with cljs-test-runner

richiardiandrea22:09:39

but yeah I can have a :main

lwhorton22:09:31

is there a way to turn off parallel-build? it’s listed in the user guide as unsupported

thheller22:09:04

I added support for that recently yes

thheller22:09:09

but why would you?

thheller22:09:50

just :compiler-options {:parallel-build false}

lwhorton22:09:19

well have i got a story to tell you …

lwhorton22:09:40

the short version is the roman01/cljss library has a race condition on atoms, and i think it can be avoided by turning off parallelism

lwhorton22:09:26

if you peek here there’s a ton of context to build up in your head, but you can see there’s a suspicious reset-env! cls followed by a future reference to cls (that’s not a deref): https://github.com/roman01la/cljss/blob/master/src/cljss/builder.clj#L10-L19

thheller22:09:33

no idea whats happening but all that looks very cache-incompatible

thheller22:09:45

may need to turn off caching