[Discussion] Built-in Messaging API
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 10.5k
- Forks
- 564
- PR merge metrics
- No merged PRs in 30d
Description
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.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the linked Chrome messaging documentation, trpc-chrome, webext-core's proxy service, the event-framework POC, and webext-bridge. Compare their support for the listed messaging contexts and extension architectures. Done requires an agreed API design and scope; the issue names no implementation files or tests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- api, developer-experience
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100