@webext-core/proxy-service Help with Context

[dever23b]

Hello:

Thanks for writing all of this. You've been a massive help to simplifying extension development.

I'm trying to migrate my messaging over to the proxy-service, and I've run into three issues. I can't tell if I'm just not using your code properly, or if this is unsupported.

1. Sometimes my content scripts need to trigger actions based on their current tab. In the past, I simply included sender.tab from the message listener when I invoked the code that needed to run in the service worker context. When I migrated everything over to proxy-service, I couldn't find a way to access sender. Is this supported? If not, would you be willing to support it?

2. Due to my issues with (1), I decided to use your messaging package directly to create a single listener that runs alongside proxy-service and wrote a very basic getCurrentTab function that returns sender.tab to the requesting content script. Then I refactored my code to first call getCurrentTab for the tab, and then send the tab as an argument using your proxy-service. This works, but it has the side-effect of requiring multiple listeners. Is there any way to integrate a messenger from messaging with a service defined in proxy-service so that they can all be bundled in one listener?

3. When I first attempted to migrate over to your proxy-service, I did not quite understand the documentation and I created a multitude of separate services. This created a mass chaos of log entries, as several listeners were all receiving every event, and made debugging very challenging. I just realized that I could create an object with service names as the keys and service instances as the values. This is fantastic for simplifying logs as well as creating proxies when multiple services are needed. However, once I refactored to use a monolithic service, I started running into issues with the this context on proxied requests. All of my services are defined as classes. Now, when the class method is invoked, the this is wrong and the method does not have access to the internal class properties. Example:

// VerificationService.ts
import { CreateLogger } from "@/util/logger";

class VerificationService {
  private log = CreateLogger('Verification Service');
  
  public async verify() {
    this.log.write('Attempting verification');
    // ... do verification stuff
  }
}

export type { VerificationService }
export const verificationService = new VerificationService();
------
// messaging.ts
import { createProxyService, registerService } from "@webext-core/proxy-service";
import { verificationService } from "@/services/VerificationService";
const services = {
  verification: verificationService
};

export public register() {
  registerService("services", services);
}

export public createProxy() {
  return createProxyService<typeof services>("services");
}
------
// background.ts
import { register } from "@/util/messaging";

export default defineBackground({
  type: "module",
  main() {
    register();
  }
});
------
// content.ts
import { createProxy } from "@/util/messaging"
const services = createProxy();

await services.verification.verify();

The call in content.ts results in a message process that eventually invokes the verify() method, with a this of the services object. When the method runs, this.log.write fails. I'm struggling to figure out how to get around this, or if it means I cannot use the proxy service.

[aklinker1]

I couldn't find a way to access sender. Is this supported? If not, would you be willing to support it?

It's not supported unfortunately. It was an oversight in the initial design, I never needed it personally, but other RPC libraries have been created since that support this.

With the current API design, it's not possible. Would be a breaking change and complicate things considerably. I'd recommend a different messaging library, like trpc-chrome or @webext-pegasus/rpc.

However, once I refactored to use a monolithic service, I started running into issues with the this context on proxied requests. All of my services are defined as classes

This should be fixed, thanks for the report. I never use classes, so I often miss things like this when I add support for them lol

[dever23b]

Thanks for getting back to me!

This should be fixed, thanks for the report. I never use classes, so I often miss things like this when I add support for them lol

I spent a few hours trying to refactor the structure of the object I passed to registerService to make it work, but I wasn't able to come up with a working solution. It seems like my issues are caused by this line, but I never got good enough with reliably modifying this to offer an alternative. I think that, at least the case of my example, simply calling the fully qualified method (i.e. realService.verification.verify in my example) without explicitly setting the context would work for calling class methods. However, I understand why you bind the method for other implementation styles. I would like to offer help in the way of a PR, but I'm not quite sure what the best way is to handle that without a messy interrogation into the type of realService.

[aklinker1]

Could you open a PR with a test case that fails? Then I can take a shot at it

[dever23b]

Sure, I will work on a fork, write some test code, and get back with you

[dever23b]

Alright. I got stuck in the weeds trying to create a PR, so instead I created an example project to demonstrate this issue as well as my workaround. I know it isn't what you asked for. I'll keep working on it and hopefully figure out how to translate this into a PR. I'm still figuring out Git & GitHub, so please forgive my ignorance.

I wasn't exactly sure where to put my example code in my clone of your project; it seemed cleaner to make a separate project, but then I couldn't figure out how to override the dependencies to use my local clone. I settled on creating a working demo of the issue before I ran out of time. I will revisit this tomorrow and take another stab at it.