This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-11-25
Channels
Does someone understand this JS behavior?
> function f(...xs) {return xs};
undefined
> f.apply(null, [[1,2,3]])
[ [ 1, 2, 3 ] ]
> f.apply(null, [[1,2,3]][Symbol.iterator]())
[]f.apply to avoid realizing lazy collections passed with apply to vararg functionsI guess this is why CLJS has its own applyTo stuff, I did a similar thing in squint now
2Found another way to improve squint + CLJS compatibilty. JS stringifies keys when you use non-string keys in objects.
In an Advent of Code solution I found someone using (myself in 2017) {[0 1] :whatever} . So now squint supports it and it also works with get because of the way JS works.
https://squint-cljs.github.io/squint/?repl=true&src=KGRlZiB4IHtbMCAwXSA6Zm9vCiAgICAgICAgWzAgMV0gOmJhcn0pCgooZ2V0IHggWzAgMF0pIDs7ID0%2BIDpmb28KKGdldCB4IFswIDFdKSA7OyA9PiA6YmFy
When I first got started working on our React/Redux/Immutable frontend, I tripped over the weird stringify keys thing in JS: I was trying to build a data structure like I would in Clojure(Script) and couldn't figure out why something wasn't working... and eventually realized JS was turning my structured keys into strings and they were no longer comparing equal like I expected.