Rum. And narrowing it down to a simple code block isn't easy. But I think I have a working theory — the functions get cached somewhere and they do reference an atom, just a different one, because each render creates a new one and they keep referencing the previous one.

For your component with the local state/atom, did you use defc or defcs ? https://github.com/tonsky/rum#components-local-state

> rum.core/defcs is used instead of rum.core/defc. It allows you to get hold of the components’s state in the render function (it will be passed as a first argument).

Thanks Michael — I do know these things, this application has ~85k LOC and has been developed over the last 5 years or so. And yet — things still manage to surprise me sometimes.

I now know that some components deep down do not get updated (keeping old closures) and using an atom does not help, unless that atom is part of component state, otherwise every render gets a different atom. Very hairy. I'm brute-forcing it by using rum/with-key to force updates.

@jrychter ok, i didn't quite understand the request which is more complex than i initialy thought. Good luck.

Thanks! I should have explained it better.

Where is is called from? env/compiler gets populated by the cljs compiler and makes such data visible at compile time, so that's info available in macros.

(cljs.analyzer.api/ns-resolve 'cljs.core 'map)

Ah that might be it, I was trying to call that at runtime

A self-recursive async function should be similar.

@U2FRKM4TW that won't blow the stack?

i didn't know JS had tail recursion

My knowledge of JS is limited - better check it rather than trust me. I think it shouldn't blow up the stack if you don't await the self-call. Otherwise, the setTimeout solution should work.

got it, thanks!

re-com has a nice approach. Many arguments can be either atoms or concrete values. It check conditionally derefs them all.