Clojurians Log v2
cherry 2022-09-13
FWIW I’ve been playing around with a new j/js macro in js-interop, inspired by these experiments. An example namespace written this way - https://gist.github.com/mhuebert/11407a1c0a1761daf01df0436c66db3d
• All destructuring is ^js by default in fn/defn/let
• All literals are objects/arrays (except for stuff that should not be rewritten so that clj forms like fn/defn/let/loop still work)
I did not go so far as to automatically rebind things like assoc/assoc!/merge and so on, still use j/* variants
so far I’m finding it quite pleasing to work with for very interop-heavy code. without j/js, that ns would be absolutely full of ^js hints and j/let, j/fn and so on which I find tiresome to write and read. One can opt out with ^clj or ^:clj metadata at any point.
j/!get ?
undocumented unchecked get
(`j/get` doesn’t throw if you pass it nil as an object, j/!get does)
aha
looks pretty useful :)
but I wonder if I can add support for this in nbb 😅
well, definitely postpone even trying to answer that until it is stable 🙂
i don’t think the macros do anything too crazy
right
in nbb, the js-interop macros mostly fall back on the runtime behavior since it's not a compiler
so (j/get-in [....]) will not optimize anything at compile time
i think that’s fine
and I wonder if your js/macro also takes that into account?
in terms of behaviour the compile time stuff is only important for google closure related nonsense (key renaming)
this mainly is built on j/lit and then the destructuring of j/fn j/defn j/let
but previously j/lit stops at list boundaries whereas this keeps going
makes sense
it will always be a bit of a finnicky thing because it needs “knowledge” of other macros in order to know what can (not) be parsed as js literal
true