-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Messaging architecture #1
Comments
Thanks for looking into this! Overall, I want to keep this issue in the back of our minds, but focus on other things first (error reporting, testing infrastructure), as that will inform Additional Considerations
Throughout the code, you'll see places where the original design didn't support all the cases, so I had to introduce new versions of "lift", or not use the "lift" approach entirely and fall back to switch statements I suspect we'll need to turn the background page into a message bus/router. The other components might need to have a message queue to handle retries/resends/etc. Responses
We should also look into other prior art from major OSS extensions to see if there's any ideas we can grab. For example:
The way to remove this coupling is most likely to share a TypeScript types (i.e., the Protocol), but not any implementation code. This could ensure type safety and that all messages are handled
I think there might even be some triple hop ones of Dev Tools -> Background Page -> Content Script -> Page Script
Could you give an example of this? I'm not sure I follow
It becomes an API evolution problem, that analogous to what you've have on any client + server architecture. The API has to evolve in a way that's backward compatible From telemetry, we know which extension versions are still deployed. So can use that information to help know when we can make backward incompatible changes
I can't find the documentation link, but I believe this is the case when the background page is set as persistent (which is the default). Chrome will download the extension in the background, but won't install until you restart Chrome For helping users stay up-to-date, the options are:
|
We discussed about the various routes in a different thread, so I'll link it here for future reference: |
I like the current setup for a few reasons:
However there are some issues:
We can discuss this further to see whether these issues exist. I can also look into improving messaging without losing the good parts.
I mentioned I had already thought about a possible (explicit) messaging architecture, but this did not carry over the function types.
webext-messenger example
Also I find the code sharing with PB.com problematic because that introduces another invisible step that does not guarantee at all that the shared functions have the same signature. I found that Chrome occasionally does not update the extension until you completely remove it and reinstall it. Refined GitHub users are occasionally a few months behind for no apparent reason. We can discuss why this was implemented and if there's any alternative to it.
The text was updated successfully, but these errors were encountered: