In CLJS, what is the best way to make AJAX calls? I see there is this library https://github.com/r0man/cljs-http but could one just as easily use js/fetch and if so, is there a pro to using a library?

There is some way to run closure-compiler "simple" > prepack > closure-compier "adv" with cljs-build?

@tkjone cljs-ajax is good

also re-frame-http-fx if you're using re-frame

I'm having an issue with using npm modules

getting the WARNING: JSC_JS_MODULE_LOAD_WARNING. Failed to load module "react"...

is it possible clojure 1.9.0-alpha20 breaks a lot of cljs tooling? i've had a lot of trouble using it with cljs on both figwheel (lein) and boot-cljs. i think part of it has to do with handling of NaN in cljs; i'm seeing things like ##NaN in the cljs.test build output. works fine on alpha19

"Invalid format: 1504569600000 is malformed at ("0" "0" "0" "0" "0")" Anyone come across similar errors in advanced compilation? Everything works fine with no optimizations and I can't work out where the problem is.

I'm working with dates, the number is a js/Date .UTC

Comming to clojure(script) from a react/js/node background I'm a bit confused as to what libraries I should try first. Any suggestions?

@karlstefan What do you want to do? A good thing about Clojurescript is that you have easy access to Google Closure. This and the language itself cover a lot that you might usually need libraries for.

Is google closure still, to this date, superior to the latest solutions available with webpack and co @danielstockton

?

@hmaurer I'm pretty sure webpack is still behind in terms of dead code elimination and code splitting, mainly because closure is written in such an explicit/verbose style.

(->> [] (apply max)) is nil. (->> [] (apply max) inc) is NaN. But (inc nil) isn't NaN, it's 1. What am I missing here?

that looks strange indeed.

in javascript, 1 + NaN == NaN. However, 1 + null == 1

(->> [] (apply max) inc) => NaN smells

IMO it should return nil or throw an error

if null + 1 == 1 in JS, I'd argue Clojurescript should forward the madness from JS

Hi. At advanced compilation, I try to leave out foreign libs like React and load them separate. I like to do it because we have many apps using the same React version (and other foreign libs). Is it even a good idea not to have one big JS file these days?

I filed https://dev.clojure.org/jira/browse/CLJS-2358 for the inc issue

@akiel you might want to look at https://clojurescript.org/guides/code-splitting

@lxsameer I know this. My understanding is that you split your code by functionality used at different sites. But foreign libs would go to cljs-base. Than I have a different cljs-base per app, because I use different stuff from cljs itself. I like to separate stuff like React because it won’t be touched by advanced compilation.

@akiel you can put foreign libs into their own modules by their provided namespace

ie. create a :module for :react via :entries [cljsjs.react]

or leave them out entirely and just use the externs and use react from a CDN or so

@thheller Ok leaving them out and only use the externs would mean, that I build my own version of the cljsjs react lib - right?

But I could also try to define a react module. Thanks!

yeah it requires a bit of minor tweaking since things like reagent expect to find cljsjs.react (in non-beta versions)

the common approach is to a create an empty namespace for everything that would otherwise be provided by the foreign libs

@mbertheau My understanding is that js awesomely has two kinds of null and cljs treats them both as nil, except when it doesn't and the js madness leaks through

correction to the above:

(inc js/undefined)
NaN

^ there’s your issue

And just to add to the madness: (number? NaN) ;; true

❤️ js

@mbertheau the JIRA issue you opened is not a bug, in general it’s best to ask here and wait for someone who contributes to ClojureScript to respond before opening an issue

(apply max []) in Clojure throws

so the ClojureScript behavior has nothing to do with max, but arity checking

and we do not currently check primitive arithmetic ops like (inc ...) for perf reasons

@dnolen Ok, but I still don't understand what's going on. A call to max isn't arity-checked, so it's value is what? And second, why does it matter how inc got its argument value (if (apply max []) does evaluate to nil)?

if something throws in Clojure and it doesn’t throw in ClojureScript it’s safe to assumed it’s behavior is undefined in ClojureScript

the exact same thing is true for passing non-numbers to arithmetic operators

that throws in Clojure

there’s nothing to understand here btw

we don’t check these annoying undefined cases for perf reasons, that’s it

@dnolen Is it wrong to say that (apply max []) is JS undefined, and nil is JS null, and JS undefined + 1 is NaN, whereas JS null + 1 is 1?

yes to say (apply max []) returns JS undefined is not correct

that whole operation is undefined period

it could throw if we come with a reasonable way to do that, so you cannot depend on the result

It is undefined currently, isn't it

to believe that (inc nil) returns anything at all is similarly unwise

@mbertheau it doesn’t matter what it currently is

you cannot depend on the behavior anyway

It does matter in practice to me because knowing which things have "undefined behaviour" without compiler support is quite hard

of course that’s implied - and you have to live with that

or contribute a brilliant to solution to this multi-year conundrum 🙂

After all, in practice, ClojureScript behaviour has to be explained to the developer who uses it in terms of the various JS VMs execution environments

what? no

JS specification - nothing to do with VMs

and in this case, it’s not defined at all as I already stated

Hmm, I don't know how relevant the JS spec is in practice. What matters to the developer right now is what browsers actually do.

@mbertheau what?

it’s completely relevant

we generate EcmaScript 262

we don’t generate JS for browsers

anyways, we could probably solve the arithmetic issues but it would be fairly dramatic change with wide ranging repercussion

which aren’t obvious if you haven’t been following ClojureScript dev for the last 6 years

so haven’t done anything about it as of yet

I don't deny that, I just need to know what's going on. You have to admit that the behaviour described in the beginning is very unexpected to the unsuspecting developer.

sure, doesn’t mean we’re going to do anything about it without thinking it through

for some ideas about how this might be done read https://clojurescript.org/news/2017-07-14-checked-array-access

So the take-away is, when you get nil from something, it can be JS undefined or JS null, which behave differently in different situations.

oh that’s a completely different thing

which was a bit obscured by your examples

we treat undefined and null as nil yes

since undefined doesn’t really have a useful semantic in Clojure(Script)

What exactly does "treat" mean in that context? When are JS undefined and JS null "coerced" to nil?

the coercion only happens if you are testing for nil i.e. nil?

i.e. x != null

and during printing of course

Which happens during printing on the REPL I assume

Ok. So when you see an expression printed as nil or test if for nil, be aware that using the same expression in a different context may not be the same as using nil in that context, because the JS value can actually be undefined or null.

yes but when could that ever matter?

@dnolen Is there a list of things the behaviour of which are undefined? Or is just the missing arity-checking?

except in this case of passing an invalid value to some other thing

The unsuspecting developer can't tell that the nil they see in the repl is actually an invalid value.

@mbertheau there’s no list, there’s lot of little edge cases

@mbertheau you can’t pass nil to inc

so it doesn’t matter if it’s actually undefined or null in the slightest

Sure: (inc nil). See? 🙂

hrm?

see what? you can’t pass nil, it doesn’t matter the rep

Then what do you mean "I can't"?

nil effectively unions null and undefined

if you can’t pass nil then you can’t pass those things

When I do pass nil to inc, it comes out as (null + (1)) on the other end.

(inc nil) is meaningless (I’m repeating myself, and I need to switch gears here)

Saying (inc nil) is meaningless may be the extent to that ClojureScript cares, but since that code compiles and a similar situation can easily appear in practice, its meaning in JS matters a lot to a developer in my opinion.

noted and I’ve said all I’m going to say about this for now 🙂

Allright with me, I have my take-away. Thanks for your work with CLJS! I enjoy it very much 🙂

Anyone have a recommendation for a clojurescript webgl/canvas library? Perhaps something that integrates with Pixie?