Clojurians Log v2
Clojure programming
Channels
Apps
clojurescript
daveliepmann 2025-09-05T18:21:41.866899Z
What is the expected behavior of a CLJS atom when it is created with an invalid initial state per its validator? For example:
(atom {} :validator (constantly nil)){}. I thought the CLJS-specific clause in the docstring might explain it:
> If the current state is not acceptable to the new validator, an Error will be thrown and the validator will not be changed.
But no, the validator is set, and the atom above refuses e.g. (swap! assoc :foo :bar).
caleb.macdonaldblack 2025-09-05T20:45:21.197699Z
Yeah doesn’t look like it behaves the same. Docs seem to suggest it should.
> • Validators work as in Clojure
> Atoms work as in Clojure.
https://clojurescript.org/about/differences#_vars_and_the_global_environment
Creating the atom in Clojure calls a private function: https://github.com/clojure/clojure/blob/b775c8a289339b4a8fb3f1800a017147c53b0b42/src/clj/clojure/core.clj#L2063 which the uses the set-validator! function
Clojurescript uses deftype to create an object with the validator as a field/prop.
If clojurescript used set-validator! instead, it would behave similarly as that function does throw.
https://github.com/clojure/clojurescript/commit/df6761abf0b2b5008956c57b8591fe1b0fa7d91c
👍 1
caleb.macdonaldblack 2025-09-05T20:46:57.421679Z
Seems like a bug to me, but would need a breaking change to fix it
dnolen 2025-09-06T02:25:19.587889Z
Yeah, but this is also just a bug, probably worth fixing & calling out as a potentially breaking change - people shouldn't be relying on this behavior given the doc string.
🎉 2
dnolen 2025-09-06T02:26:25.360769Z
yeah, invalid initial state - I'd be surprised if there's a lot of code that willfully depends on this behavior
daveliepmann 2025-09-06T05:44:57.711129Z
Cool, thanks