> Optional Chaining operator (?.)
> Nullish Coalescing operator (??)
Esp chaining can have a huge impact on readability.
[0]: https://www.monkwhocode.com/2020/05/nodejs-v14-2-things-to-k...
> Optional Chaining operator (?.)
> Nullish Coalescing operator (??)
Esp chaining can have a huge impact on readability.
[0]: https://www.monkwhocode.com/2020/05/nodejs-v14-2-things-to-k...
Basic examples for null coalescing here https://byexample.xyz/javascript/ECMAScript2020/nullCoalesci...
(get-in obj [key1 “key 2” (make-key obj 3) 4] “not-found”)
There is also a simpler version for single-level access with (get obj key not-found).“not-found” can be a value or a function or a function evaluation, and the keys can be of any type, including nested maps or, if you wanna get really wild, functions.
Someday I’ll get to use this professionally instead of transpiling piles of NPM dependencies into something IE11 can work with...
Both of the new additions to JS specified in the article can be sort of done in cljs, though each one will be a function. This already fits with the existing paradigm; there are no operators in Clojure, only functions. “2 + 3” in JS is already “(+ 2 3)” in CLJS.
The Math.pow() vs “two stars operator” is kinda pointless: it can be reduced to (pow x y) with a require statement. Is that really used often enough to warrant new syntax?
Here’s how big numbers can be separated by space though. It does not handle overflows; I don’t think the JS version does either:
(defn bignum [& xs] (js/parseInt (apply str xs)))
(bignum 123 456 789)
;; yields 123456789 as a JS int
There’s an efficiency argument to be made here, in that a JS parser can do this with less overhead. But if you have that many unreadable big numbers written in your codebase, I think you have bigger problems.Oh looks like the operator is actually '?.' instead of just '?' so guess this.myOptionalFunction?.() could work but that looks really confusing in my eyes.