what is the correct way to include a macro in a *.cljc file? I currently have to put a #?(:cljs ...) line in the :require-macros part, and a #?(:clj ...) line in the :require part ... and maintaining both parts is error prone. Is there a easy way in cljc to say "include this amcro, do the right thing whether you're in clj or cljs" ?

@qqq With the recent releases of ClojureScript you can just use :require and :refer like you would in Clojure and the ClojureScript compiler will just "figure it out."

This is Implicit macro loading detailed here: http://clojurescript.org/about/differences#_namespaces

The TL;DR is that oftentimes reader conditionals in ns forms are no longer necessary.

Hi all - I’m having a problem using https://github.com/cljsjs/packages/tree/master/aws-sdk-js

I’ve added it to my project.clj and require’d it as described in the doc, but when I try to execute (let [db (js/AWS.DynamoDB.)] …) I’m getting:

~/d/cljs-aws-test> node target/main/lambda.js

/Users/colin/dev/cljs-aws-test/target/main/cljs_aws_test/main.cljs:9
  (let [db (js/AWS.DynamoDB.)]
           ^
ReferenceError: AWS is not defined
<stacktrace>

I’m sure I’m missing something obvious, but I have no idea what.

It looks like the generated JS contains: cljs.core.load_file("target/main/aws-sdk-js.inc.js");

@cfleming if you’re using a Node module you cannot require that in the normal way

(def AWS (js/require “aws-sdk”)) is what you want

externs should not come into play with Node.js unless you’re using advanced compilation for some reason, and I don’t see the point of that

@mfikes: I'm reading through that; what version of cljs do I need to use that?

@dnolen Ah, thanks - it’s odd, I’ve seen examples using the other way, but that seems to work, thanks.

They may have been old or something, I’m not sure.

@qqq Any of these: r1.9.293 r1.9.229 r1.9.227 r1.9.226 r1.9.225 r1.9.216 r1.9.211 r1.9.198 r1.9.183

@mfikes: I'm using 1.9.229 so I'm good; thanks for the insight! glad someone finally solved this annoyance, my :require and :require-macros section was getting unmanageable

i'm trying to figure out the repl workflow when working on an isomorphic clojure app (clojure server with clojurescript frontend, using figwheel). i want to be able to send code to my server repl from my clj code, but also to figwheel from cljs. anyone have any recommendations on this? it feels pretty janky right now (i've been booting lein figwheel and connecting to that but that seems to be the frontend repl)

Sadly that's going to be really dependent on your tooling/setup

I did it on one project via a nginx instance that proxied my CLJ server endpoints, and combined them with my figwheel endpoints into a single unified API.

But that took about 3 devs about 2 days to configure, lol

wow. yeah i mean for now i really only need the repl on the server so my temp solution is just running the server repl, connecting to that, and manually launching figwheel from the repl

>That will only work for type 1 components. For type 2 and 3 (and also for type 1 so that reagent can cache results), put the components in vectors like (defn root [] [component]) This 🙂

@jtmarmon if you are an emacs user, replique supports this workflow (without figwheel though) https://github.com/EwenG/replique.el

Question: is it possible to replace the usage of the Google closure compiler with uglifyJS if I do not call any Google closure Library code. Like, If I compile with optimizations simple, could I then run everything through browserify/webpack followed by uglifyjs. The reason I am thinking of this is, the differences between and merits of Google closure and uglidyjs aside, both optimize the code to a degree. But with uglifyJS, I could require a node dependency and be reasonably certain that it would be optimized; whereas with Google closure incompatible code is abound in popular libraries. If it is possible, could figwheel still work?

@emccue uglify cannot do effective dead code elimination, using anything other than Google Closure will likely result in at least a 2X larger artifact

The only thing that comes close to Google Closure for DCO, inlining & co (in my experience) is the ocaml compiler via Bucklescript/Reason, but this is not for raw js.

Hmm, what would results be if I ran advanced compilation with "require" defined as an extern, then ran that file through webpack/uglifyJS

@emccue I don’t understand what you are trying to accomplish by doing that

Well, right now I am trying to use react-player as per the tutorial on bundling foreign libs. I have been having troubles getting leiningen to include the bundled dependencies before the generated code, so the only solution I have working is including the foreign bundle in the html before the app.js This is unsatisfactory for me, mainly because I don't know how to do tests properly: if I test my app.js and call js/something that will be nil in testing but not in the browser. Literally catting the files together works, but that is pretty inelegant. So the thought was that I could bypass the whole 2 separate bundles thing by running what cljsbuild spits out through a second watcher; but to be fair all of this is rooted in my incompetence.

I would rewind and try to get the foreign lib approach working

Leiningen doesn’t have anything to do with that

it’s just a ClojureScript compiler thing - you need to add a foreign lib and your own ClojureScript code must require that dep

Yeah, I think I might be getting a silent error there. The synthetic namespace is required in my .core, so I don't think that is the issue. If I change the path to be invalid the build breaks, so it is at least seeing the bundle, but when I check window.deps nothing was defined (I posted the config I was trying a bit above, If you have any insights, or can rule that out as the source of trouble)

@emccue doesn’t the tutorial cover this and doesn’t it work?

I would get it working w/o involving whatever other variables your project may imply

The tutorial works completely

It just stops at putting the bundle in a separate script tag

oh the tutorial doesn’t describe how to avoid that?

I haven't yet found a tutorial on foreign libs that covers this use case

@emccue there is no use case here. foreign libs works the same doesn’t matter what you are doing.

have you seen this https://github.com/clojure/clojurescript/wiki/Dependencies#bundling-foreign-javascript-code?

I have; I'll give it a try again when I am out of work. Do foreign libs require an :externs file when you are accessing it through the global namespace?

@emccue currently foreign libs always need externs

That may be my issue then; I'll try it with a blank externs file

If that ends up being the case; perhaps the compiler should output a warning if there is a :foreign-lib without an extern provided

@emccue this doesn’t make as much sense as you might think since you might not use advanced compilation

Yeah I guess that makes sense; I will report if this works at a later point

@jtmarmon: in figwheel you can switch the cljs repl from front end to backend when you :cljs/quit

is there any documentation around providing a javascript lib from clojurescript? e.g. create a react component with reagent to be consumed by non-clojurescript app

@tankthinks not really because it’s not that practical

JS users will get a whole bunch of things they can’t use - like the standard library etc.

hmmm … my “problem” is my team is using clojurescript but we don’t mandate that other teams have to use it too

if you want to expose something that’s not so hard

we can easily consume their components but what if I want to share something with them

^:export works on individual fns, and it works via goog.exportSymbol

this prevents renaming so outside people can call into your ClojureScript even if it’s advanced compiled

thanks @dnolen, I have some reading to do

I’ll start with the goog.exportSymbol documentation

if I ^:export a fn, am I going to export any called fns too?

No, just the one you told it to export

thanks @emccue

would you recommend going down the ^:export route for sharing react components that I know will be consumed by non-clojurescript apps, or should I simply write those in js?

As far as I'm aware that will be fine with the caveat (at least in reagent) that you should wrap your components (which are returning persistent vectors; not exactly directly consumable) with r/as-element

https://reagent-project.github.io/news/news050.html

(sorry reactify-component)

Om is likely a different story

thanks again @emccue! I didn’t see that reagent doc … should have read the “news” 😃