New Chrome messaging library: extension-bus

[Likely Logic]

Hi all,

I just posted a messaging library for Chrome and Firefox, MV2 and MV3 extensions:

• github.com/davestewart/extension-bus

It has a bunch of useful features, mainly:

• cross-process messaging
• named buses to easily target individual processes
• named and nested handlers to support more complex use cases
• transparent handling of sync and async calls
• transparent handling of process and runtime errors
• a consistent interface for processes and tabs

Effectively, you set up endpoints for each process, and every other bus can call and target those endpoints via path.

I've been running a version of it for the last few years, but have recently rewritten it and decided to open source it. I've included in both the code and the docs my accumulated knowledge on all things messaging, so feel free to use, comment or critique.

Best wishes,
Dave

[Oliver Dunk]

Hey Dave,

This is great - thank you so much for sharing! Would love to hear your experience building it and what challenges you ran into.

I'll have a play soon but appreciate the really comprehensive README in the repository.

Is there any typing for message request and response payloads yet? If not, that would be a cool addition.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/0acf3925-70fe-4e81-87da-786d18ad6c61n%40chromium.org.

[Likely Logic]

Hey Oliver!

You mean making the function call generic, or some kind of build process to generate types for the nested handlers?

I considered typing the call function, but as it guaranteed to succeed (even if returning null) is there any advantage over just const result: SomeType = await bus.call('path/to/handler') ?

I'm open to suggestions / corrections of assumptions!

[Likely Logic]

Perhaps something like this?

https://github.com/davestewart/extension-bus/pull/3

On Tuesday 16 January 2024 at 13:03:17 UTC Oliver Dunk wrote:

[Oliver Dunk]

Exactly like your PR!

I just replied there with some thoughts but generally that's what I was thinking.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Likely Logic]

Grand :)

I've added some Chat GPT research about correctly typing the paths too, so potentially all handler paths, their payloads and return types could be compiled to aid with autocomplete.

[Andrzej Karaś]

Hi Dave,

Your event bus looks very well crafted and documented code.

A year ago I created something way similar. It's also implemented differently compared to your solution. But it is not so feature-rich, yet. I did not have time to work on this.

You can take a look at this here: https://github.com/andrzejkaras/browser-extension-event-bus.

Best wishes,

Andrzej

[Likely Logic]

Hey Andrzej!

Always good to review other approaches!

Are you leveraging storage events there to simulate messaging?

[Andrzej Karaś]

> Are you leveraging storage events there to simulate messaging?

Exactly. This allows me to react to events without implementing custom code. When webextension-polyfill will support session storage I will add also quasi in-memory event bus.