Fork me on GitHub
#shadow-cljs
<
2018-04-26
>
daveliepmann10:04:40

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?

thheller10:04:45

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

daveliepmann10:04:32

at expo-test/DemoApp/App.js

thheller10:04:43

that is unused?

thheller10:04:08

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

thheller10:04:31

> Do not run ANY of the printed instructions.

daveliepmann10:04:37

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

daveliepmann10:04:06

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

thheller10:04:38

hmm maybe something is cached then somewhere?

daveliepmann11:04:51

I think I've cleared the cache successfully and am experiencing the same issue. I now suspect it could be that I was unable to download a version of the iOS app that supports QR codes, so I am loading the app on iOS thru the Expo desktop app.

daveliepmann12:04:53

trying now with manually sending link

thheller10:04:51

rn cache not shadow-cljs cache

thheller10:04:27

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

daveliepmann11:04:03

no worries, thanks for the quick response

grav11:04:28

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.

thheller11:04:59

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

grav11:04:27

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

thheller11:04:03

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

grav11:04:52

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

grav12:04:40

@thheller works perfectly with :exports. Thanks!

zarkone12:04:40

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]])
   ))
and I get The required namespace "live.client.components" is not available, it was required by "filemporium/client/live.cljs".

zarkone12:04:13

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

grav12:04:49

@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

zarkone12:04:36

thanks, tried also with :node

thheller12:04:52

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

zarkone12:04:05

will try out now without it

thheller12:04:07

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

grav12:04:10

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

thheller12:04:33

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

zarkone12:04:39

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

zarkone12:04:50

yes, it seems like that

thheller12:04:06

reader conditionals only work in .cljc files

👍 4
thheller12:04:24

that should definitely show a better error

zarkone12:04:35

wow, right! this is components.cljs

zarkone12:04:13

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

thheller12:04:19

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

thheller12:04:30

so kinda keeping it hidden 😉

zarkone12:04:09

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

zarkone12:04:47

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

thheller12:04:53

Core as in the Clojure/ClojureScript projects.

thheller12:04:55

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

thheller12:04:00

but I needed it so its in there 😉

zarkone12:04:15

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 😞

zarkone12:04:32

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

kanwei20:04:46

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

thheller20:04:36

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

kanwei20:04:23

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

kenny21:04:14

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.

kenny21:04:02

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.

kenny21:04:42

i.e.

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

;; this is the React component? 
countup

kenny21:04:21

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

thheller22:04:35

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

thheller22:04:40

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

thheller22:04:15

:default is definitely confusing

kenny22:04:19

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

thheller22:04:40

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

thheller22:04:06

unlikely that is going to change anytime soon but it might

kenny22:04:12

That's frustrating.

thheller22:04:54

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

kenny22:04:47

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.

thheller22:04:30

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.

thheller22:04:19

its pretty annoying ...

kenny22:04:38

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

kenny22:04:19

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

thheller22:04:09

you can use whatever name you want for it

thheller22:04:39

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

kenny22:04:54

Oh, that makes sense.

thheller22:04:07

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

kenny22:04:30

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

thheller22:04:27

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.

4
thheller23:04:47

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

thheller23:04:02

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

kenny23:04:17

So I'd be safe using myalias/default?

kenny23:04:43

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

thheller23:04:25

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

thheller23:04:39

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

kenny23:04:34

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

thheller23:04:30

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

4