You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 UX.
In particular, the messaging API should support the following:
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.
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.
@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.
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 UX.In particular, the messaging API should support the following:
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?
import { ... } from 'wxt/rpc'
import { ... } from 'wxt/events'
import { ... } from 'wxt/messaging'
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. Thought 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.
The text was updated successfully, but these errors were encountered: