How do I require a development library so that it will get dead code eliminated? Example: (ns foo (:require [dev-library])) (when goog.DEBUG (dev-library/do-something!) (println "Hello development!")) (println "Hello world!") AFAIK, dev-library will not be DCE'd. So how should I change the code? Some macro magic?

@rap1ds use :preloads build config

@thheller Aha! Thanks!

I’d like to share something I’m working on. It’s a declarative web audio engine (think React for Web Audio API). In the spirit of data-oriented programming, the graph is just data. As a side-fx of it, it’s really easy to serialize/deserialize. Also, it’s extremely straightforward to extract part of a graph into a function, thus it is both generative and highly composable. It feels like a perfect “glue” for building non-trivial audio graphs. https://github.com/cljs-audio/cljs-audio

I am running into a strange error under :advanced compilation using shadow-cljs. I am consuming this fork of Timidity using npm: https://github.com/chr15m/timidity It works well in dev mode. Under :advanced compilation I am seeing the following error:

app.js:598 Uncaught (in promise) ReferenceError: $jscomp is not defined
    at p.load (app.js:598)
    at rm (app.js:1394)
    at app.js:1395
    at app.js:1372

load(l) {
                            const f = this;
                            return $jscomp.asyncExecutePromiseGeneratorFunction(function*() {
                                V("load %o", l);
                                if (f.destroyed)
                                    throw Error("load() called after destroy()");
                                f._audioContext.resume();
...

I'm using Browser REPL and what I'm seeing is that the first time I evaluate ns form in a namespace it takes quite a long time. Evaluating a single ns form causes a dozen of network requests, each taking close to 1 second. This means that the total time to eval is closer to 10 seconds. Sometimes this causes nREPL to time out. I'm seeing this same with and without Cider piggieback. The response of the repl xpc request is a bunch of goog.addDependency statements. What might be causing this? Is there any way to make this faster? Any ideas on how to debug this further? Screenshot attached.

What does this error means Uncaught Error: No protocol method IDeref.-deref defined for type undefined:

Using @foo when foo is undefined/nil

But I have defined all reagent atom with default value

that doesn't matter, you are likely not deref'ing the actual atom

The subscription is returning nil, then it's calling deref on nil, probably

Probably not best to call @ on behalf of some other calling code automatically. You can do (when-let [derefable (sub [:blah])] @derefable) to protect against that

You're talking about subscriptions, but OP doesn't mention them - they can be using Reagent without re-frame. Also, it's never a good idea to use that pattern - a subscription must never return nil. If it does, it means it doesn't exist - means, the error is elsewhere.

hmm, maybe it'd say nil in the error? If so, maybe you're thing is actually not defined. But I've seen it a lot when a nil sub causes that problem

oh that's true, they might not be talking about subs

And yeah, subs should be defined before you call them, but sometimes folks typo or whatever. Then the above error doesn't help them sus it out much

The above error provides a stacktrace leading to the exact location of the subscription usage. The when-let pattern just hides the error.

okay so i should look at the subs definition ?

Yeah, there's sometimes cases where you want to make a component generic wrt a given sub, so you might pass in the sub path from the outside. Those situations are much more likely to cause issues with derefing. Depending on how you want the function to work, you may want it to not fail hard when a bad sub path is given.

@anshbenew If you use re-frame subscriptions, there should be a clear warning in the JS console saying which subscription ID is not found.

@john This is a very narrow, specialized, case. I would absolutely not recommend it to novices. A usage of a non-existent sub is an error, 100%. It should be fixed, that's it.

@p-himik it is just showing me this error

On a large enough code base, you might run into it though. Fair argument about trying to avoid it though

@anshbenew 1. I have no clue if you're using re-frame or not - you still haven't confirmed it 2. You don't have source maps enabled. Figure out how to enable them with the tooling that you use and you'll be able to see the relevant CLJS code 3. This is more #reagent related

Yes, I am using re-frame with reagent.

okay will try to enable source maps

I enabled source maps it is showing Uncaught ReferenceError: goog is not defined

goog.addDependency("base.js", ['goog'], []);