Hello. I'd like to raise this question to clojure cljs team: What is the idiomatic way to access a JS field ?
β’ aget works, but its docstring says that is specific for arrays
β’ unchecked-get works, but its docstring says that it is internal. Also, it is not a function (can't apply unchecked-get .. )
In the thread, thheller talked about "update unchecked-get docstring and give a functional treatment", that I agree that could be a simple solution for this problem.
See original thread
https://clojurians.slack.com/archives/C03S1L9DN/p1706014470056979
In what circumstances would you possibly want to apply a getter like that?
users inputs a JSON payload and writes a JSON pointer
then call (apply unchecked-get (js/JSON.parse json-input) (parse-json-pointer pointer-input))
I don't understand. Does parse-json-pointer return a collection of keys? Do you expect an object getter to work like get-in but without an extra vector?
I'd go for unchecked-get . You could do this:
cljs.user=> (js/Reflect.get #js {:a 1} "a")
1
but probably less performant.If you (for some reason) need unchecked-get with apply, just wrap it in a function
o wait, that doesn't work since the field must be known at compile time
by "function treatment" I mean adding a defn unchecked-get to cljs.core CLJS side, which then just delegates to the macro. just so that apply works. the macro stays as is. this trick is used many more times in cljs.core
I was wrong about compile time, this just works:
cljs.user=> (defn ah-get [obj fld] (unchecked-get obj fld))
#'cljs.user/ah-get
cljs.user=> (ah-get #js {:a 1} "a")
1and don't use Reflect. thing[foo] is perfectly fine to do in JS and that is what unchecked-get provides
> I'm thinking in "work the same as aget but objects"
aget is a macro though. :)
try (str aset) and you'll see there is a runtime function for it as well
aget is also a function, which is the trick I'm referring to ...
Ah, shoot, right.
Still get occasionally burned by the fact that CLJS is in both .cljs and .cljc when reading the code.
Yes, it is a https://github.com/clojure/clojurescript/blob/v1.11/src/main/clojure/cljs/core.cljc#L1012 and a https://github.com/clojure/clojurescript/blob/v1.11/src/main/cljs/cljs/core.cljs#L504
@souenzzo thereβs really no point in avoiding gobj/get
assume it will work for at least another 10 years
we will probably eventually replace the various GCL namespaces since most of them are simple - but breaking stuff has no benefit - this ainβt the JS ecosystem - thereβs no value in breaking stuff
small note: Post announces 1.11.132 but lists contributors as having contributed to 1.11.51
fixed thanks ππ½
small typo in "Note that Google stopped provided regular releases many years ago"
similarly, > Google is not going to remove Google Closure Library (GCL) or remove the API docs or doing anything that would be detrimental to ClojureScript. should be revised like so > Google is not going to remove Google Closure Library (GCL), remove the API docs, or do anything that would be detrimental to ClojureScript.
thanks! fixed
release forthcoming, feedback welcome before I publish this post tomorrow - this also addresses the worry around GCL
the release itself will be out soon (triggered a build just a little while ago)