cljs-dev

souenzzo 2024-01-23T13:06:39.697359Z

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

p-himik 2024-01-23T13:07:59.155739Z

In what circumstances would you possibly want to apply a getter like that?

souenzzo 2024-01-23T13:10:48.905919Z

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))

p-himik 2024-01-23T13:11:29.863709Z

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?

πŸ‘Œ 1
borkdude 2024-01-23T13:11:39.941899Z

I'd go for unchecked-get . You could do this:

cljs.user=> (js/Reflect.get #js {:a 1} "a")
1
but probably less performant.

πŸ‘ 1
borkdude 2024-01-23T13:12:05.799159Z

If you (for some reason) need unchecked-get with apply, just wrap it in a function

borkdude 2024-01-23T13:12:27.124019Z

o wait, that doesn't work since the field must be known at compile time

thheller 2024-01-23T13:13:02.132629Z

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

borkdude 2024-01-23T13:13:39.052349Z

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")
1

πŸ‘ 1
souenzzo 2024-01-23T13:15:00.893269Z

@p-himik yes. but I'm thinking in "work the same as aget but objects" @borkdude I'm currently using this.

thheller 2024-01-23T13:15:29.230589Z

and don't use Reflect. thing[foo] is perfectly fine to do in JS and that is what unchecked-get provides

p-himik 2024-01-23T13:16:06.323759Z

> I'm thinking in "work the same as aget but objects" aget is a macro though. :)

borkdude 2024-01-23T13:16:36.630129Z

try (str aset) and you'll see there is a runtime function for it as well

thheller 2024-01-23T13:16:39.854119Z

aget is also a function, which is the trick I'm referring to ...

p-himik 2024-01-23T13:16:53.363979Z

Ah, shoot, right.

p-himik 2024-01-23T13:17:27.682869Z

Still get occasionally burned by the fact that CLJS is in both .cljs and .cljc when reading the code.

dnolen 2024-01-23T14:12:00.681599Z

@souenzzo there’s really no point in avoiding gobj/get

dnolen 2024-01-23T14:12:18.154009Z

assume it will work for at least another 10 years

dnolen 2024-01-23T14:14:18.278859Z

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

βž• 1
dpsutton 2024-01-23T20:23:47.952389Z

small note: Post announces 1.11.132 but lists contributors as having contributed to 1.11.51

dnolen 2024-01-23T20:42:29.304429Z

fixed thanks πŸ™πŸ½

πŸ‘ 1
2024-01-23T21:08:36.571509Z

small typo in "Note that Google stopped provided regular releases many years ago"

hifumi123 2024-01-23T21:43:36.030859Z

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.

dnolen 2024-01-23T23:32:03.183469Z

thanks! fixed

dnolen 2024-01-23T20:20:11.626209Z

release forthcoming, feedback welcome before I publish this post tomorrow - this also addresses the worry around GCL

πŸ‘ 1
dnolen 2024-01-23T20:20:35.074439Z

the release itself will be out soon (triggered a build just a little while ago)