@jamie857 you need window or just global context?

would js/Electron work for you?

@jamie857 goog.global

that's assigned to the global context regardless of browser or Node.js

I ran into some issues trying to compile a ClojureScript node.js project. Basically, when I run cljsbuild with optimizations :none I get something that works, but any other optimizations produces Cannot find module "../moment", which comes from cljsjs.moment. The code that requires moment is already working in an existing browser app with advanced optimizations… Has anyone seen anything like this?

I have reproduced the issue in this repo: https://github.com/cjohansen/cljs-compiler-woes

@christian767 I'm assuming you need compilation under Node.js for some reason? Like AWS Lambda?

did you try skipping advanced? There's not much benefit, try :simple

yes, the problem is reproducible with :simple

I wanted compilation in order to have a single file, and not use the goog module loading stuff

ok looked over your readme

the error is leading you towards the likely cause

Cannot find module \"../moment\"

isn't really a ClojureScript thing

you said you're using cljsjs.moment but that doesn't seem true based on that error

hah, really?

more specifically, I tracked that line down to a moment locale

it looks like an attempted load of the moment node module

yep, from cljsjs.moment.locale.nb

but that won't work

I don't see how that could work in the browser

it got me stumped too…

the strange thing is that I didn’t touch any of the code using moment - it’s just :required from an existing browser app

maybe my node program is introducing another moment somehow? :thinking_face:

:npm-deps false in your build

we default to reading node_modules but that will change in the next release

hmm, ok

anyway - the build does work in the browser in the repo I posted above. even with optimizations

no idea about that, I don't use moment

sure

FWIW the problem is in the CLJSJS package

it is a normal AMD wrapper that defaults to calling require when running in node

;(function (global, factory) {   typeof exports === 'object' && typeof module !== 'undefined'       && typeof require === 'function' ? factory(require('../moment')) :   typeof define === 'function' && define.amd ? define(['../moment'], factory) :   factory(global.moment)}(this, (function (moment) { 'use strict';

ah, right

still strikes me as odd that this would not fail with no optimizations

dynamic requires

@dnolen sure, but my test actively loads the offending code and uses moment to print a formatted date

it works in :none due to the way the debug loader is setup for node

hah!

ok, thanks. definitely learned something today 🙂

you could use shadow-cljs where its just (:require ["moment" :as moment]) for both node and the browser 😉

noted 🙂

haven’t looked into that yet

my biggest problem right now is that I’m trying to reuse some existing code, so the moment require isn’t in my new code. and I’ve seen the same problem with React etc

so I’ll probably just settle for no optimizations for now

cljsjs.moment will work as well in shadow-cljs since the shim already exists https://github.com/thheller/shadow-cljsjs/blob/master/src/main/cljsjs/moment.cljs

question: the unoptimized package (which is a CLI tool) seemed a little slow to me (longer startup times than I’m used to with pure node apps). I assumed this was due to loading lots of files, and that a simple compile to one file would alleviate it

but this was just an assumption. would :simple optimized cljs be faster than :none?

yes, and :advanced even faster

right

😬

you’re saying that I could even use cljsjs.moment successfully with optimizations with shadow-cljs?

yes

well maybe

🙂

sounds like I need to finally check out shadow-cljs

actually I'm not sure .. people just use (:require ["moment" ...]) usually

cljsjs really is just a hack to get the browser working

I’ll give it a shot, thanks

:advanced is not necessarily faster

in fact in some cases it can be worse

short story, we expose all the flags for actual runtime perf stuff

:static-fns true :optimize-constants true are the ones that matter

oh, cool

that probably means I can opt out of name munging too?

:advanced just doesn't matter for Node.js in my opinion

:simple only munges internals

where would it be worse?

in the past I would observe Closure creating shared fns for similar code

but this is a VM perf hole

hmm would that not apply for v8 in the browser?

it applies to all engines

advanced isn't necessarily faster

but code size matters more so tradeoff

I agree that its not all that useful to go for :advanced in node but it does make a difference in startup time

(not that that matters)

interested though. never explored that aspect

back in when there was ton of data structure work, I would benchmark both :advanced and :simple + the other needed bits

the later often had the edge

but not big enough to really care

but there is significant gains from :none to :simple right?

yes

we expose all the perf flags

so I think the biggest different is going to be loads

(of libs)

:optimize-constants doesn't make sense for :none so that is a big hit

do I use these individual options in addition to, or in place of :optimizations?

:optimizations is just a Closure flag

all this other stuff ClojureScript

to dispel a common misconception - perf is almost entirely from ClojureScript

these flags control the ClojureScript compiler and take effect regardless of :optimizations

of course

thanks

the one critical thing that Closure does under :simple and higher

removal of IIFE (immediately invoked function expressions)

I'm having some issues with using reagent with cljsjs/material-ui. When using material-ui/Input (after adapting) as a controlled input, and using android irefox (desktop Firefox works fine), the input does not correctly fire events. Lets say I tried to type "example" into the input. When "e" is pressed, the input reads "e" When "x" is pressed, the input reads "eex" When "a" is pressed, the input reads "eexea" When "m" is pressed, the input reads "eexeaeexm" When "p" is pressed, the input reads "eexeaeexmeexeap" And so on. This bug only occurs on Firefox for android, and does not occur on Firefox Focus for android. Has anyone run into this before?

I suspect that problem probably affects direct usage from JS - if so, might want to check the material UI issues first?

I haven't seen any issues on their github, and pure js material-ui on their example site seems to work fine.

and versions match?

I did notice that the on-change function was called twice, although Im still not sure why that would cause problems, unless there is something wrong with the event itself.

Not the latest version of material-ui, but didnt see any mentions of firefox in their changelog.

might not be Firefox specific - but ok

I would probably debug this a bit further then to make sure it's not something logic related or ClojureScript specific (which I'd be skeptical about)

I got it down to a pretty simple failing example: (defonce text (reagent/atom "")) (defn input [] [material/Input {:value @text :on-change #(reset! text (-> % .-target .-value))}])

I would drop some printlns to validate my assumptions in Firefox

It seems that in all other browsers, on-change is called once, with the correct event.target.value. In firefox it is called twice: once with event.target.value as "", and once with the screwy result.

Not sure why this only happens in cljs, as I dont see anything cljs specific.

I doubt it has anything do with CLJS

just whatever else you are using

like Reagent, etc.

Found the reagent channel, Ill ask there.

I have a question about figwheel! When I make a new reagent project using lein new reagent, how would I require a javascript file? I'm thinking of a hypothetical scenario where I wanna make a new clojurescript project but reuse my react components!

@odd.andreas the most robust standard way is https://clojurescript.org/guides/webpack

you can't really just require JS files since usually there's a lot of assumptions baked into your JS

ok thanks! I was hoping to be able to import js files in a less robust way just while I was experimenting I guess 😄

you can't because they aren't "just" JS files

in the old days when people shipped real "just" JS files like jQuery etc. this was trivial

Anyone have experience is dockerizing clojurescript app?

Is there any way to start nrepl with cljs.main?

I’ve got an if syntax exception now manifesting itself as:

java.io.NotSerializableException: clojure.spec.alpha$regex_spec_impl$reify__2436

I think it’s coming from adzerk.boot-cljs.util/serialize-object util.clj: 56

(so probably tooling specific then)

@borkdude https://github.com/boot-clj/boot-cljs/pull/181 & referenced issue, boot-cljs tries to serialize exceptions to move them from threads to another but that fails for some classes

thanks @juhoteperi

@borkdude Hmh, as I haven't come up with proper solution ten months I think I'll just merge the workaround, so fix should be available soon

anyone cop this? https://reactjs.org/docs/hooks-intro.html 👀 🤯

a little reagent in your React starting in 16.7 😏

In the clojurescript compiler config for a reagent project, I have :foreign-libs with one of the libs having :global-exports of {create-react-class preactCompat.createClass}. This was working w/ earlier cljs but isn't working now - the generated js looks like $goog$global$$["preactCompat.createClass"], but to be able to read an object property for an export, it should be $goog$global$$["preactCompat"]["createClass"] or something equivalent. Does this look like a bug or is there another way we're supposed to export object properties as namespaces?