This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-09-18
Channels
- # aleph (45)
- # aws (4)
- # beginners (56)
- # boot (2)
- # cider (45)
- # clara (2)
- # cljs-dev (9)
- # cljsrn (31)
- # clojure (71)
- # clojure-dusseldorf (8)
- # clojure-gamedev (1)
- # clojure-italy (22)
- # clojure-nl (1)
- # clojure-russia (46)
- # clojure-sg (1)
- # clojure-spec (5)
- # clojure-uk (40)
- # clojurescript (30)
- # community-development (3)
- # cursive (17)
- # data-science (1)
- # datomic (18)
- # emacs (3)
- # figwheel (1)
- # fulcro (19)
- # hoplon (12)
- # jobs (5)
- # leiningen (42)
- # off-topic (12)
- # om (2)
- # onyx (41)
- # re-frame (19)
- # ring-swagger (1)
- # rum (3)
- # shadow-cljs (4)
- # specter (7)
- # unrepl (2)
- # vim (25)
- # yada (24)
Hello folks, I was checking js->clj
on an object that is not really an object (from AWS Gateway query params)
so (type my-obj)
returns nil
so (identical? (type x) js/Object)
fails and the object is not converted
however, (goog/typeOf my-obj)
works fine and returns object
my question would be, should we add a check using goog/typeOf
in js->clj
for completeness?
@richiardiandrea hm, have you tried to extend IEncodeClojure on that weird object?
IMO js->clj
is a can of worms and nobody could possibly touch it because that would break others' people code
@darwin I haven't no, but it would probably work as workaround, it still feels there I should not be doing that, it should be supported OOTB. Probably there are reasons behind using type
only
Would like to know which ones, for awareness of JS weirdnesses 😄
let me know if a JIRA is necessary or I am completely on the wrong path here 😉