Fork me on GitHub
#clojurescript
<
2024-07-04
>
grounded_sage06:07:10

How can I update :rawId and other values. When I use js-interop I can j/get the value and modify it. But assoc! and update! fails to work. Using native interop then throws errors as it can't infer the types.

PublicKeyCredential {rawId: ArrayBuffer(20), response: AuthenticatorAttestationResponse, authenticatorAttachment: 'platform', id: 'TeG4f39j0LjAyuvTbfifORcXv7E', type: 'public-key'}
authenticatorAttachment
: 
"platform"
id
: 
"TeG4f39j0LjAyuvTbfifORcXv7E"
rawId
: 
ArrayBuffer(20)
response
: 
AuthenticatorAttestationResponse {attestationObject: ArrayBuffer(182), clientDataJSON: ArrayBuffer(231)}
type
: 
"public-key"
[[Prototype]]
: 
PublicKeyCredential

grounded_sage06:07:32

It seems there is no clear way with a prototype and I just have to create a new object?

p-himik08:07:00

What exactly is the error when you use (set! obj -rawId ...)?

thheller08:07:35

assuming this is https://developer.mozilla.org/en-US/docs/Web/API/PublicKeyCredential then it is read-only property that you cannot change

👍 1
grounded_sage10:07:41

Oh 😅 I was figuring out how to send it back to the server and something I read said you have to change it from the array buffers to base64 to serialise to json. Will read through these docs some more.

grounded_sage12:07:06

Indeed I missed this somehow during my hacking.

jrychter08:07:36

Hmm. I think I found a bug:

;; Compiling this function will issue a warning:
;;   cljs.core/+, all arguments must be numbers, got [#{nil clj-nil} number] instead
(defn test-bug [some-value some-other-value]
  ;; Change some-value to true and the warning goes away.
  (let [buggy-value (if some-value
                      (case some-other-value
                        1 42))]
    (+ buggy-value 1)))

p-himik08:07:51

Why is this a bug? buggy-value can be nil in your example.

jrychter08:07:30

Can it be [#{nil clj-nil} number]?

p-himik08:07:17

[x y] means that the type of the first argument is x and the type of the second argument is y. buggy-value can be nil, so its type is assigned #{nil clj-nil}. It's not a bug, it's an intentional behavior.

jrychter08:07:39

Also, change the case to (if some-other-value 1) and the warning will disappear. Even though buggy-value can still very much be nil.

p-himik08:07:27

This part is probably incorrect. But type inference is known to be incomplete.

jrychter08:07:31

In my real code, this warning pops up in a branch of code where things can't be nil. I noticed this, becasuse it makes development (with figwheel) a bit annoying, with the warning popping up on every change.

p-himik08:07:12

So what's the code? If something can't be nil there, it doesn't correspond to your original example.

jrychter08:07:20

(defn test-bug [some-value some-other-value]
  ;; Change some-value to true and the warning goes away.
  (let [buggy-value (if some-value
                      (case some-other-value
                        1 42))]
    (when some-value
      (+ buggy-value 1))))

p-himik08:07:41

Without looking at the actual analyzer code - yeah, probably a limitation of type inference. I would wrap the whole function body in that when, no need to check twice.

jrychter08:07:14

I'm not looking for advice on workarounds — it isn't that simple. It took me a good while to extract this minimal example, the actual code is fairly complex and the calculation and usage of + are in totally different places. I do think this warning is a bug (it will also go away if you change the case to an if statement, so I thought I'd write about it.

👍 1
jrychter07:07:37

Let me see if I can explain it better, and perhaps I should not have used the word "bug". I'm looking at this now:

(defn test-bug [some-value]
  (let [buggy-value (when some-value
                      ;; Replace this case with 42 and the warning goes away
                      (case some-value
                        1 42))]
    (when some-value
      (+ buggy-value 1))))
This will produce a warning. But if I replace the entire (case) with a number (say, 42), the warning will disappear. That's the first thing that I found confusing. The second thing is that (+ buggy-value 1) does not get executed at all if some-value is nil. So in my real code, this warning is incorrect, because the + can never be executed with a nil parameter.