I just ran into this.
js->clj works perfectly in a Node environment.
It doesn't work in a Firefox add-on, where an object is created in the add-on code and processed by cljs code loaded through `require`.
This cost me quite a bit of debugging time, because of course it works fine when you test it inside the same source file, and works fine in Node, which is a much simpler JS environment.
JS engine documentation makes it very clear that you should not do comparisons against prototypes, because it's nonsensical:
The naïve workaround with the current implementation — to convert a JS object to a cljs object in the calling context – is difficult, because of course the calling context is pure JS (so it doesn't even have a js->clj function!), and if it did, it would be a different cljs, and the same problem would occur elsewhere when handling that cljs object.
Using `(js->clj (.parse js/JSON (.stringify js/JSON o)))` is an expensive alternative, and doesn't work for rich objects (including JS's own Date type).
So much as it's tempting to say "too hard, wontfix", this makes building a non-trivial library in ClojureScript very inconvenient indeed.
- Provide a js->clj function that assumes that the input is a JS type, and converts it through sane JS-appropriate logic. E.g., it calls Array.isArray(o) to determine whether the input is an array. Object is the final fallback.
- Adjust the existing js->clj function that inverts its test: checking whether the input is a ClojureScript type first (because of course they're all objects), and otherwise falling through correct JS type determination code.
For the moment I am going to write the former myself, because I don't have any more time to waste.