cherry 2022-09-13 | Slack Archive

Fork me on GitHub

mhuebert08:09:00

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.

mhuebert08:09:31

#Also sent to the channel

https://github.com/applied-science/js-interop/pull/32

borkdude08:09:00

j/!get ?

mhuebert08:09:22

undocumented unchecked get

mhuebert08:09:33

(`j/get` doesn’t throw if you pass it nil as an object, j/!get does)

borkdude08:09:52

aha

borkdude08:09:43

looks pretty useful :)

borkdude08:09:54

but I wonder if I can add support for this in nbb 😅

mhuebert08:09:25

well, definitely postpone even trying to answer that until it is stable 🙂

mhuebert08:09:36

i don’t think the macros do anything too crazy

borkdude08:09:17

right

borkdude08:09:44

in nbb, the js-interop macros mostly fall back on the runtime behavior since it's not a compiler

borkdude08:09:56

so (j/get-in [....]) will not optimize anything at compile time

mhuebert08:09:05

i think that’s fine

borkdude08:09:12

and I wonder if your js/macro also takes that into account?

mhuebert08:09:43

in terms of behaviour the compile time stuff is only important for google closure related nonsense (key renaming)

mhuebert08:09:23

this mainly is built on j/lit and then the destructuring of j/fn j/defn j/let

mhuebert08:09:42

but previously j/lit stops at list boundaries whereas this keeps going

borkdude08:09:57

makes sense

mhuebert08:09:33

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

borkdude08:09:50

true

mhuebert08:09:31

replied to a thread: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.

https://github.com/applied-science/js-interop/pull/32