What do you mean by "seem to break"?

Well if you look at the inspector when opening the page it says "Uncaught TypeError: $APP.qr is undefined"

Ah, that page already has a deployed release app, right? The JS console has this on my end: Cannot read properties of undefined (reading 'prototype'). That should be easy to track. In your case, the error is even more clear. I'm 90% certain it's due to externs. During dev builds, the compiler leaves x.someLongName just as that, and during a release build it may turn into something like x.qr if the compiler isn't told that someLongName should not be renamed because e.g. it comes from some thirdparty library or from data.

This is a nice article on externs: https://code.thheller.com/blog/shadow-cljs/2017/11/06/improved-externs-inference.html

Welp you're getting a different error? 😞

Ah chrome gives that error

Same line though

The real error seems to be the same - something is undefined. Maybe we have different versions of Chrome, maybe different flags, maybe different OSes.

My error is on Firefox so yea

So one surprising thin is that if you search for $APP.qr in https://nyancad.github.io/Mosaic/app/js/common.js it's actually in there.

Since this started happening after I split up editor.js and common.js into modules, I'm kinda inclined to think it's something weird about the module part.

https://github.com/NyanCAD/Mosaic/blob/e0c5fe7d47c8aa03f3f012aeee24226a7924c043/shadow-cljs.edn#L15-L17

Have you tried the approach from the article I linked?

So just add :compiler-options {:infer-externs :auto} ? Lemme try.

Not "just" - you will have to change the source code at places where shadow-cljs complains. The relevant documentation section: https://shadow-cljs.github.io/docs/UsersGuide.html#infer-externs

Well it does not complain as far as I can tell

Hmm, no clue then. If you don't know where exactly you need to put ^js and shadow-cljs doesn't tell you where it can't infer externs, maybe there's some issue with externs inference when it comes to projects with multiple modules. If so, I'd try creating a minimal reproducible example and asking in #shadow-cljs

ah wait..

Yea no... I thought I had put the thing in the wrong place but... no change

I'm not sure it's related to externs, as the common.js file actually does include the name it's trying to use, so something weird is going on

The name $APP.qr might be there and still be undefined.

And that "there" might not be the right "there". :) But it can indeed potentially be something unrelated to externs. But I don't think I've ever seen an issue that was manifesting itself only in the release build that wasn't about externs.

So on line 2977 of common.js it says $APP.qr.prototype.Xa=function(){return this} so... yea that's why I'm not sure why it'd be related to externs, because the names in the two modules seem to match up.

Could it be some setup function that's not called or something, leaving it undefined?

Yep. Which, in turn, can be a consequence of externs not being inferred correctly somewhere. :) It's impossible to guess, you would have to debug it.

Just not sure where to start debugging.... I guess I can try to undo the modules and see if that solves it. Are externs used between modules, or only between cljs and js code?

No clue. Regarding debugging - you can try intermediate optimization methods and see if that solves it. You can also try following the code and the values back up the stack from the error while comparing the working and the non-working versions side-by-side.

Thanks, I'll see what I can do 🙂

Hmyea simple optimizations makes it work soooo :thinking_face:

So it's probably about names, yeah.

But making it a complete build instead of modules resolves the problem too, so it something about the interface between the modules that's the problem

Then I'd definitely ask in #shadow-cljs given how much it's tool-specific.

Yea

I'm using shadow-cljs so maybe that's where I should be looking, huh?

Indeed, it's documented.

Browser apps don't really deal with environment variables. Query parameters tacked on the URL of your browser app may be an option to pass in stuff like that. What problem are you trying to solve?

you can use environment variables at build time though, I don’t have much cljs experience but that s a common pattern in elm/js/ts to feed like API urls and other stuff that differ from localhost to staging to prod.

Yeah I used shadow-cljs to handle it. Thanks folks

If a reload hook is executed if and only if a compilation was successful, why not just get the current time right there in the hook?

because the reload can happen after a compilation by a significant delay

so we can make an edit, see a reload, and that wasnt the “right” reload

Ah, right.

I mean, its not a mystery. there are about 100k lines of cljs and cljc

I work on an app that is close to that size and I only see those kinds of reload times when changing things at the very root of the dependency tree (which is very rarely). if the generic (perhaps ill fitted) advice I gave in the channel doesn't speak to your situation, then I guess we're making lemonade.