hi, using the firebase lib from cljsjs (aset (js/firebase.auth) "languageCode" "fr") expression does work when compiled with :advanced option.

https://github.com/firebase/firebase-js-sdk/blob/master/packages/firebase/externs/firebase-auth-externs.js firebase.auth.Auth.prototype.languageCode; appears, which i suppose the firebase wrapper in cljsjs uses

why then this does work with :advanced compilation and how can i fix it?

Hi. How would one write (cljs.test/is (thrown-with-msg? CLJS-class #"foo" (throw (ex-info "foo" {})))) - as in, what should take the place of CLJS-class?

js/Error I think is what you want?

@dominicm Yes, that worked - thanks!

Is there a library that takes html and generates reagent compatible hiccup?

Anyone know why these two expressions would print different results?

cljs.user=> (let [state (cljs.js/empty-state)]
       #_=>   (cljs.js/eval state '(def x 1) {:eval cljs.js/js-eval} prn)
       #_=>   (cljs.js/eval state 'x {:eval cljs.js/js-eval} prn))
{:value 1}
{:value nil}
nil
cljs.user=> (let [state (cljs.js/empty-state)]
       #_=>   (cljs.js/eval state '(def x 1) {:eval cljs.js/js-eval, :context :expr} prn)
       #_=>   (cljs.js/eval state 'x {:eval cljs.js/js-eval, :context :expr} prn))
{:value 1}
{:value 1}
nil

The docs for cljs.js/eval claim that :context :expr is the default: http://cljs.github.io/api/cljs.js/eval

I'm sure I'm missing something simple.

@zane assuming you are running things exactly like that the first time cljs.user.x = 1 will be set in JS

since you don't restart the runtime inbetween that value is still there the second time

@thheller The thing that is confusing me is why simply cljs.js/evaluating x right after (def x 1) prints nil if :context :expr is not set.

@thheller Additionally, I don't believe defining things via cljs.js/eval (self-hosted ClojureScript eval) ever affects the environment of the caller. Do you have a different understanding?

I'd test it but I'm away from my computer.

@zane everything you eval is eval'd in your runtime (eg. the browser), nothing is isolated. empty-state only affects the CLJS analyzer state, not the state of the runtime itself.

@thheller Then what's happening in the first let?

I assume it's interpreting it as a statement and the docs are wrong?

uhm yeah that maybe right. not actually sure if cljs.js/eval does some async stuff. if it does it may just be async not having eval'd yet.

Ah, yeah. Could be a race condition.

it may just be the :context :expr thing alone since the code will just not emit anything to eval

@thheller Thanks for the help! Is there something I could read to understand what the analyzer state is/is for?

I don't have a good mental model of how self-hosting works at all.

hehe me neither. always hurts my head thinking about it. analyzer data is used by cljs.analyzer for code generation stuff. It keeps all data about defn&co defined in your namespaces.

@thheller Got it. Does that apply to macros?

not actually sure in self-hosted but I guess it will keep some infos about macros in there as well yes

looks like the doc might be wrong? https://github.com/clojure/clojurescript/blob/r1.10.516/src/main/clojure/cljs/analyzer.cljc#L686

Yeah, eval* calls ana/empty-env which defaults to :statement

Good catch @zane!

Might be a good chance to contribute a fix, if haven't had a chance to yet

@john I've been looking for one!

Nice! If you're interested, I'd check in with the devs over at #cljs-dev and get an opinion on whether it's a doc string error or a code error.

If you want to try changing the default to :expr then you should probably make sure to run the self host tests to make sure everything still works.

Another strategy would be to let ana/empty-env default still to :statement and check for lack of :context in eval*'s params and give it :expr if so. And test against that.

But if it's a doc string thing, there looks to be a number of different fns that declare :expr as the default in their doc strings, so they may be wrong too.

If nobody sees it this weekend, somebody should probably see it this week. Remember to sign the contributor agreement https://clojurescript.org/community/contributing if you want to end up sending in a patch.