What's the idiomatic way to do x.y.z.w += 1 in clojurescript?

(-> x .-y .-z .-w inc)

That doesn't sound right to me... inc is pure, isn't it? https://clojuredocs.org/clojure.core/inc

x.y.z.w is going to be left unchanged

Ah sorry you wanted to mutate the value?

Use set!

I know, but it's going to be (set! (-> x .-y .-z .-w) (inc (-> x .-y .-z .-w))) which seems kind of mouthful

I looked and there doesn't seem to be anything like swap! but for properties

Mutating properties is probably supposed to be ugly. 😄 I guess that’s what you have. :thinking_face: If you need to do that often, perhaps you could write your own helper macro or function

can you grab the reference to .w (or .z ) in a let binding and set! that?

@valtteri Yeah, that makes sense

@lasse.maatta Seems it would suffice for my case

@zhuxun2 if you are ok with using a library, js-interop has an update-in! macro that would look like (j/update-in! x [.-y .-z .-w] inc) or if the keys are static, (j/update-in! x [:y :z :w] inc) (https://github.com/applied-science/js-interop)

We have a very strange bug in our advanced CLJS compiled front-end app. We have some specs referring to other specs:

(s/def :foo/foo string?)
(s/def :bar/bar :foo/foo)

alpha.cljs:121 Uncaught Error: Unable to resolve spec: :foo/foo
    at u2a (alpha.cljs:121)
    at RY (alpha.cljs:518)
    at tY (alpha.cljs:513)
    at BY (alpha.cljs:314)
    at query.cljs:41

CLJS version 1.10.764

I don't see this release on github btw: https://github.com/clojure/clojurescript/releases

Probably it's better to not load spec at all in our advanced CLJS app

we're not instrumenting anything anyway

compile it with :pseudo-names true, it could tell more

it just points at spec-impl where it tries to resolve that other spec by name.

which it can't find, while it was defined just before.

Repro or it didn't happen, I know. It was introduced by a non-related commit in our codebase, so hard to reproduce probably.

with pseudo names, you should be able to debug it in chrome devtools even without source maps, just step through formatted js code

with help of (js-debugger) you can pin-point interesting places

just by chance, aren’t you using multiple javascript contexts? e.g. a webworker and the main page?

I think we might have hit some heissenbug. Requiring this namespace earlier in our app seems to get rid of this issue. But still very weird, since these specs are in the same file...

we're not using webworkers. anyway, we're getting rid of these specs anyway (in production at least)

Are you requiring the namespace that :foo/foo is defd in the namespace that :bar/bar is defd in?

It sounds like you’re not

When compiled, namespaces are ordered topologically according to who requires who. If you don’t require a namespace, but rely on some global state to be setup in it (like a spec) then there can be orderings where that state isn’t initialized when the code runs