Hi folks, I'm replicating https://github.com/shadow-cljs/expo-test and want to make sure I am on the right page. I'm able to get the DemoApp running in the Expo app on my iOS device, but it displays (and live-reloads) text from the JavaScript source rather than what I see in the ClojureScript source ("Hello World from CLJS! 1"). Is this expected?

@daveliepmann not sure I understand what you mean? which javascript source?

App.js

at expo-test/DemoApp/App.js

that is unused?

are you running the react-native things? they don't need to be running

> Do not run ANY of the printed instructions.

I don't believe I'm running the react-native things, because I didn't run any of the printed instructions

(I did the first time I went thru the README, but have stopped them and restarted my machine since then)

hmm maybe something is cached then somewhere?

hmm

rn cache not shadow-cljs cache

right

investigating

got a work call now. I'll be back in a bit.

no worries, thanks for the quick response

Can I get shadow-cljs to generate a handler function for use with AWS Lambda? When configuring a Lambda function on AWS, I can specify a handler like myFile.myHandler, which magically makes AWS look for exports.myHandler in myFile.js.

@grav :node-library does this. :exports {:myHandler your.ns/handler}. so it is basically exports.myHandler = your.ns.handler;

great!

I tried adding something like the last statement directly to the generated js, but it didn’t work. I’ll use the :exports way

you'll need to use release builds with AWS though. it probably wont unterstand the dev stuff

I did generate it using shadow-cljs release. Must’ve done something else wrong.

@thheller works perfectly with :exports. Thanks!

hi! sorry, completely new user here. Just tried to do this:

(ns live.client.components
  (:require
   [reagent.core :as r]
   #?@(:node [[filemporium.ssr.http-client :as client]]
       :cljs [[live.client.subscriptions :as sub]])
   ))

without reader conditionals compilation seem to work fine, i.e. I get warnings from this namespace

@zarkone Two things about reader conditionals - I’m pretty sure the @ shouldn’t be there scratch that - I’ve never seen :node before and can’t find it documented. I’m not sure you can discern on compile-time? On run-time you could ask if some node-specific api exists

thanks, tried also with :node

@zarkone only one branch is taken when you use reader conditionals

also, @ is for splicing here, taken from https://groups.google.com/forum/#!topic/clojure-dev/8YJJM8lJuQs

will try out now without it

I suspect that you want to take the live.client.subscriptions always?

@zarkone yes, you’re right, didn’t know about that one 🙂

🙂

The required namespace "live.client.components" is not available happens when the compiler failed to parse the ns form

@thheller no, even without any code I still get the same error

yes, it seems like that

oh hehe

live.cljs

reader conditionals only work in .cljc files

that should definitely show a better error

wow, right! this is components.cljs

thank you, hope to figure out such things by myself next time 🙂

np. I think the feature isn't properly documented at all yet since Core is kinda against it and declined the feature request

so kinda keeping it hidden 😉

sorry, Core of what? you mean that we can't extend reader conditionals on plain clj/cljs ?

no, it's actually pretty obvious -- I just haven't used cljc for some time

Core as in the Clojure/ClojureScript projects.

https://dev.clojure.org/jira/browse/CLJS-2396 this was declined

I don't want to promote a feature that doesn't work officially in CLJS

but I needed it so its in there 😉

yes, I think I've came across this earlier. I actually think that yes, clj/cljs "isomorphic" compilation is usefull, but node/browser/etc separation is mandatory, i.e. more important.. so not sure why this was declined 😞

I was even thinking about switch back to cljx before I knew about shadow-cljs. thank you very much!

@thheller not sure the new output-wrapper is working, still getting no wrapping even in 1-module builds

@kanwei didn't make a new release yet. its only in master for now. probably make a new release in a bit. just got home.

oh, it was tagged 2.3.8 so I thought it was in

cool

The ES6 Import to CLJS Require table (https://shadow-cljs.github.io/docs/UsersGuide.html#_using_npm_packages) has been helpful but I can't seem to get a particular package to work, and my knowledge of JS packages is quite limited. I am trying to use react-countup (https://github.com/glennreyes/react-countup#usage). I have added react-countup "3.0.3" to my package.json and npm install'ed. I have ["react-countup" :as countup] required in my ns. countup/CountUp is undefined though. If I look at the countup object itself, I can see a few functions defined: formatNumber and startAnimation but not the class: https://github.com/glennreyes/react-countup/blob/master/src/index.js#L105. I must be missing something simple here.

Ah, I believe because their import is import CountUp from 'react-countup';, I do not need to do countup/CountUp. It should just be available under countup.

i.e.

(:require ["react-countup" :as countup])

;; this is the React component? 
countup

A closer reading of the bits below the table yields the answer 🙂 It's actually this:

(:require ["react-countup" :as countup])

;; this is the React component
countup/default

@kanwei just pushed 2.3.9 which has :output-wrapper. also documented it here: https://shadow-cljs.github.io/docs/UsersGuide.html#output-wrapper

@kenny (:require ["react-countup" :default CountUp]) would be the translation of import CountUp from 'react-countup';

:default is definitely confusing

Right, but I don't really like the whole :refer-esque approach. I much prefer to use aliases.

true but be aware that the default import/export in ES6 has special meaning and might not always be /default in the future.

unlikely that is going to change anytime soon but it might

That's frustrating.

agreed but unfortunately the JS world decided that it is going to be this way 😞

The default thing seems silly to me. It saves two whole characters when import'ing. Perhaps I don't fully understand the advantage of it.

in ES6 the default export is technically a standalone variable. it is not part of the object you would get with :as. The .default property only exists to make things compatible with CommonJS require. strict ES6 does not have this.

Bleh.

its pretty annoying ...

I'll begrudgingly use the :default syntax in the :require 😣

Is there a way to rename it? I was hoping to name my Reagent component CountUp as well.

you can use whatever name you want for it

(:require ["react-countup" :default Foo]) works just fine

Oh, that makes sense.

Thanks!

be aware that standard ES6 still has not accepted :default so you might actually be better off using countup/default for the time being if you care about compatibility. https://dev.clojure.org/jira/browse/CLJS-2376

Is David's comment there mostly wanting to wait for ES6 to accept (or not) :default?

David is very hesitant to add features that are not in Clojure which is reasonable. Given that JS is so different I do not agree with several of his choices however. I fully expect to change his mind about this with time.

@kenny turns out I'm actually wrong. .default is part of the spec. Just re-read the spec and it is definitely defined as a getter.

:default is still useful though so that doesn't change

So I'd be safe using myalias/default?

yes

Good to know. I'd definitely prefer that over the ns :default syntax just because I like aliasing things over referring them.

yeah agreed. it just gets tiring to see thing/default everywhere depending on what JS you are working with

given that many JS files only have the default export and nothing else

Totally agree. I just created a def in my project so I don't need to do exactly that.

btw :default Foo is just syntax sugar for :rename {default Foo} so that also works in CLJS