Fork me on GitHub
#clojurescript
<
2019-04-07
>
lilactown20:04:41

man, some of the orchestration involved with chrome extensions is… it’s a lot of complexity 😅

lilactown20:04:11

in order to communicate with a tab from devtools there’s like 3 layers of message passing, and you have to keep track of which tabs are communicating to which devtools in user-land

darwin20:04:52

have you looked at https://github.com/binaryage/chromex-sample? with core.async the code looks quite simple

lilactown20:04:36

I glanced at it. I haven’t been ready to use chromex yet

lilactown20:04:08

i feel like I need to understand how extensions actually work before I use a wrapper lib

lilactown20:04:27

i’m sure core.async helps, but it’s still a lot of indirection is all 😛

darwin20:04:36

good luck with your project 🙂

darwin20:04:52

and don’t forget to share your results…

👍 4
zane20:04:05

I've read and successfully reproduced Mike Fikes's process for making ambient functions available to code evaluated by cljs.js/eval. (https://github.com/mfikes/ambient) Is there a similar process for making ambient macros available? I imagine doing so is a bit trickier.

4
zane20:04:29

What appears to work is using cljs.js/eval to evaluate (require-macros '[macro.ns.you.want]) before dumping the compiler state.

zane20:04:36

I'd be very curious to hear if there's a better way, however.

mfikes20:04:45

@U050CT4HR You'd need to compile the macros down to functions (in the corresponding $macros namespace) using (likely self-hosted) ClojureScript compiler. Your require-macros approach is doing this. This is also essentially what Planck does to cause bundled macros to become "ambient" instead of being compiled when required. (http://blog.fikesfarm.com/posts/2016-02-03-planck-macros-aot.html)

zane20:04:18

@U04VDQDDY Thanks! Got it. Glad my intuition was right here.