This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2024-07-04
Channels
- # architecture (35)
- # babashka (1)
- # beginners (60)
- # biff (6)
- # cider (21)
- # clerk (14)
- # clojure (10)
- # clojure-europe (42)
- # clojure-nl (1)
- # clojure-norway (15)
- # clojure-sweden (6)
- # clojure-uk (12)
- # clojurescript (19)
- # community-development (1)
- # data-science (2)
- # datalevin (1)
- # datomic (22)
- # gratitude (1)
- # honeysql (1)
- # hyperfiddle (8)
- # introduce-yourself (5)
- # leiningen (12)
- # lsp (18)
- # off-topic (20)
- # overtone (6)
- # pedestal (5)
- # specter (5)
- # sql (12)
- # xtdb (2)
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
It seems there is no clear way with a prototype and I just have to create a new object?
assuming this is https://developer.mozilla.org/en-US/docs/Web/API/PublicKeyCredential then it is read-only property that you cannot change
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.
Indeed I missed this somehow during my hacking.
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)))
[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.
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.
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.
So what's the code? If something can't be nil
there, it doesn't correspond to your original example.
(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))))
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.
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.
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.