[Discussion] Built-in Messaging API

[aklinker1]

Feature Request

Replacement for browser.runtime.sendMessage/browser.runtime.connect/browser.tabs.sendMessage. The APIs provided by Chrome are difficult to use, not type-safe, and leads to bad DX.

In particular, the messaging API should support the following:

• Internal messaging
• Webpage messaging
• Native messaging
• User scripts messaging
• Messaging between injected scripts and content scripts
• Messaging between an iframe injected on the page and the content script that injected it.

Additionally, there are multiple ways of architecting an extension around storage/messaging. I don't think a single solution will work for all these architechures. We may want to consider different APIs for each?

Background as an "API"	Event-based	Decentralized
import { ... } from 'wxt/rpc'	import { ... } from 'wxt/events'	import { ... } from 'wxt/messaging'

These are all the main ways I'm aware of at least.

That said, I don't like the decentralized approach, and would prefer to omit it entirely from WXT. It basically turns into the "background as an API" in the end anyways, since messages have to be passed through the background. I guess we could make an abstraction around it so it seems like you're able to message between contexts without the background, so maybe an API like that could exist.

Background as an API

Something like https://github.com/jlalmes/trpc-chrome could be good. Need to support more types of messaging though.

Also, https://webext-core.aklinker1.io/guide/proxy-service/ is very convenient to use. Though a tRPC approach accomplishes the same thing, and perhaps more elegantly?

Event-based

Made a POC for an extension based on events a while back: https://github.com/aaronklinker-st/event-driven-web-extension/tree/main/src/plugins/event-framework

Decentralized

Something like https://www.npmjs.com/package/webext-bridge could be good. Need to support more types of messaging though.

[manojhl]

I believe having a wxt way of sending Messaging API is critical, maybe create a separate package wxt-messaging to keep it as optional.

I come from plasmo ecosystem, though i use both @plasmohq/messaging and webext-bridge. I like webext-bridge way of doing things, it's simple but limited.

[aklinker1]

@manojhl thanks for the feedback! I never used plasmo's messaging APIs, I'll look at their API for reference as well.

Eventually, I plan on publishing all these extra utils (including storage and localization) as separate packages so you can use them outside WXT as well.

[spookyuser]

I also like background as an api! I don't love plasmo's messaging because there's so much setup involved to create a new api function vs trpc which is just one line.

I too have been enjoying https://github.com/sinanbekar/webext-zustand and (ofc) https://webext-core.aklinker1.io/guide/proxy-service, being able to switch between contexts makes the messaging apis feel particularly annoying soo I also like the proxying approach with everything in the bg.

Also https://github.com/janek26/trpc-browser seems to be better maintained, but the last time I tried it I kept getting error messages related to chrome ports so I haven't used it since, but I think these may have actually been because of plasmo 😬

I don't understand react server components nearly well enough to know if this is even conceptually possibly, but it would be cool if it were possible to run the react-dom server in the bg and use it as a react server for components in the content script

[aklinker1]

I don't understand react server components nearly well enough to know if this is even conceptually possibly, but it would be cool if it were possible to run the react-dom server in the bg and use it as a react server for components in the content script

Man, I have no idea how this would work lol. Maybe with offscreen documents? But I guess I don't understand why it would be useful to "server render" UI in an extension... But an interesting idea non-the-less.

I too have been enjoying https://github.com/sinanbekar/webext-zustand

Didn't know about this one, thanks for sharing!

[spookyuser]

Man, I have no idea how this would work lol. Maybe with offscreen documents? But I guess I don't understand why it would be useful to "server render" UI in an extension... But an interesting idea non-the-less.

lol me too - I think the only reason would be being able to manage all the state in one place and being able to do fetch requests and stuff without having to proxy them through the background first so I guess it would remove the need for the trpc-browser layer / js object proxy

[axuj]

@webext-core/proxy-service works very well, but after build, both ui and background will have called code. I wrote a lib that ui only use typescript, and support pass stream data in asyncGeneratorFunctions.

[aklinker1]

@webext-core/proxy-service works very well, but after build, both ui and background will have called code

Yeah, that's something I've known about for a while, but have never fixed. Would require a breaking change to fix.

Instead, I've been using trpc-chrome for my communication needs. It's a little more setup, but I think it creates a more unified API and includes tons of other features like validation.

[axuj]

@webext-core/proxy-service works very well, but after build, both ui and background will have called code

Yeah, that's something I've known about for a while, but have never fixed. Would require a breaking change to fix.

Instead, I've been using trpc-chrome for my communication needs. It's a little more setup, but I think it creates a more unified API and includes tons of other features like validation.

Validation is not as important in browser extensions as it is in web APIs, in my opinion. You can check out my library webext-rpc which works like @webext-core/proxy-service but doesn't build the dependency into the UI.

[aklinker1]

I like your library a lot! Like the API, thanks for sharing!

[manojhl]

Just mentioning @extend-chrome's https://github.com/extend-chrome/messages package which is built on promises and observables.

[Timeraa]

Just gonna comment on this, I'm currently trying my best to implement this in a good type-safe way, so far it's looking good, taking a lot of inspiration from @aklinker1's Proxy service but supporting all the possibilities and especially different ways of messaging is a bit of a pain.

I'll try to get as much progress done and open a draft PR if I can, working on a POC right now

[2wheeh]

FYI, this one looks good to reference as well: https://github.com/StyleT/webext-pegasus facebook's lexical is using it with WXT.

[spookyuser]

What's facebook's lexical?

FYI, this one looks good to reference as well: https://github.com/StyleT/webext-pegasus facebook's lexical is using it with WXT.

[aklinker1]

FYI, this one looks good to reference as well: https://github.com/StyleT/webext-pegasus facebook's lexical is using it with WXT.

Nice, yeah, that's what I'm thinking it would look like. I mentioned having a transport layer abstracted out of the more useful utils like RPC or event broadcasting.

For more details on what we want to implement: https://github.com/wxt-dev/wxt/pull/899#pullrequestreview-2217270397

However, this hasn't been a priority, so we can continue to recommend other messaging frameworks as well.

[Timeraa]

Yeah I haven't had the time to continue on it since my extension took up way too much time lately. I do want ti continue on it soon

[spookyuser]

Me too, I've been using the webext-core/proxy-service + trpc as a replacement for trpc-chrome +trpc and it's working incredibly well

[2wheeh]

@spookyuser

What's facebook's lexical?

It is a RTE framework by meta: https://lexical.dev They are using WXT on their devtools extension (where I met WXT at first): https://github.com/facebook/lexical/tree/main/packages/lexical-devtools

[aklinker1]

Oh, nice, Facebook is using WXT? That's a big win lol

[Timeraa]

That is nice indeed