Support web workers in libraries

[klausj]

🚀 Feature request

Command (mark with an x)

- [ ] new
- [ ] build
- [ ] serve
- [ ] test
- [ ] e2e
- [x] generate
- [ ] add
- [ ] update
- [ ] lint
- [ ] xi18n
- [ ] run
- [ ] config
- [ ] help
- [ ] version
- [ ] doc

Description

I would like to use Web Workers in an Angular 8 library project.

In version 8.1.1 this seems to be supported for project type 'application' only:

ng generate webWorker my-module/myWorker --project my-lib
Web Worker requires a project type of "application".

Describe the solution you'd like

Generating a Web Worker should work for project type 'library' as well.

Describe alternatives you've considered

Rewrite TypeScript worker code to JavaScript file.

[emps]

hey do any have any workaround ?

[SansDK]

Hey @klausj,

It's been a while since you opened this issue, do you have any kind of solution / workaround on how to use a web worker in an Angular library?

Thanks

[klausj]

Hi @SansDK

As a workaround I create an object URL which contains the code of a TypeScript method for the worker. The worker code is wrapped by a self executing function to be available to the worker.

// Helper class to build Worker Object URL
export class WorkerHelper {

 static buildWorkerBlobURL(workerFct: Function): string {

      // Update 2020-07-16: Try to mitigate XSS attacks
      // Should ensure a type check at runtime and reject an injected XSS string.
      if(! (workerFct instanceof Function)) {
         throw new Error(
            'Parameter workerFct is not a function! (XSS attack?).'
         )
      }
      let woFctNm = workerFct.name;
      let woFctStr = workerFct.toString();

      // Make sure code starts with "function()"
      // Chrome, Firefox: "[wofctNm](){...}", Safari: "function [wofctNm](){...}"
      // we need an anonymous function: "function() {...}"
      let piWoFctStr = woFctStr.replace(/^function +/, '');

      // Convert to anonymous function
      let anonWoFctStr = piWoFctStr.replace(woFctNm + '()', 'function()')
     
      // Self executing
      let ws = '(' + anonWoFctStr + ')();'
   
      // Build the worker blob
      let wb = new Blob([ws], {type: 'text/javascript'});

      let workerBlobUrl=window.URL.createObjectURL(wb);
      return workerBlobUrl;
    }
}

A TypeScript class which requires a worker looks like this:

export class ClassWithWorker{
 
 private workerURL: string;
 private worker: Worker | null;
 
  constructor() {
        this.worker = null;
        this.workerURL = WorkerHelper.buildWorkerBlobURL(this.workerFunction)
    }

    /*
     *  Method used as worker code.
     */
    workerFunction() {
       self.onmessage = function (msg) {
        let someInputData = msg.data.someInput;
        // Work on someInput
        ...
        // Post result
        postMessage({someOutput:someData });
       }
    }

    start(){
       this.worker = new Worker(this.workerURL);
       this.worker.onmessage = (me) => {
           let result = me.data.someOutput;
           ...
       }
       this.worker.postmessage({someInput: someInputData});
     }

    stop() {
      this.worker.terminate();
     }
}

The approach works but has some drawbacks:

• As dgp1130 has demonstrated the solution could potentially be vulnerable to XSS attacks. I try to prevent this by a type query on the type function, but I cannot guarantee that this works for all runtimes and transpilers.

• The string returned by Function.toString() seems not be well defined. It differs on different browsers and depends on the transpiler version used ( for example I had to change the code migrating from Angular 7 to 8).
  So my approach might break in future versions of browsers or build environments!

• If the worker code requires other classes they must be put inside the workerFunction. Duplicate code might be necessary.

[SansDK]

Thanks for the explanation and the example, very useful!

[TheKrisSodroski]

Just gonna drop my 2 cents, but allowing libraries to encapsulate web worker functionality away from consuming applications would be an absolute game changer.

With this, a future where we'll only be chaining awaits vs handling call backs and subscriptions isn't far off. I suspect performance would skyrocket as library maintainers would be able to offload computations completely from the UI thread.

Code quality would increase in the ecosystem as a whole.

[dgp1130]

Talked about this a bit in amongst the team. Workers have a lot of use cases for libraries. The challenge here is that workers must be loaded from a URL, and a library typically can't assume anything about the URL layout of a particular application.

Fortunately this is pretty easy to work around. Libraries can just export a function that does what they want and applications can easily import and call this function from their own worker. For example:

// my-lib.ts

export function work() {
  console.log('Does work');
}

Then the application can define a worker file which calls this library:

// my-worker.worker.ts

import { work } from 'my-lib';
work();

The worker can be started like any other by the application:

// app.component.ts

const worker = new Worker('./my-worker.worker');

The work() function can add event listeners to provide a proper service or support whatever API is useful for the library. This adds a little more boilerplate to the application, but keeps URL layout limited to the application and out of the library.

We're curious to hear if there are other use cases which might not be well-supported by this kind of design. The only one I can think of would be a library which wants to manage its workers directly (like a ThreadPool in Java), but that could be worked around and I'm not aware of any web worker use cases which fit that kind of model. You can't run arbitrary functions in a worker, so the comparison to ThreadPool isn't entirely accurate here. If there are other use cases that don't work well here, please post them so we can re-evaluate if necessary.

The workaround previously mentioned is quite clever but not usable for production.

• This introduces potential XSS security vulnerabilities (what if a malicious user tricked application code into calling WorkerHelper.buildWorkerBlobUrl() with their own user-input string?)
• Closures and global data are not packaged in the string format, so you really have no guarantee that this function will work.
  • WorkerHelper.buildWorkerBlobUrl(() => console.log(window.foo)); // window is not defined
  • WorkerHelper.buildWorkerBlobUrl(function() { console.log(this.foo); }.bind({ foo: 'bar' })); // this is undefined

[TheKrisSodroski]

That sounds nice, but ideally, libraries would automatically wire up in a consuming application.

If there were some kind of standard that we developed for workers inside a library, the compiler would be able to automatically wire up service workers correctly, would they not?

This same issue somewhat exists for assets, styles, and scripts. In order to consume some libraries, you have to modify the consuming applications angular.json sections manually.

To circumnavigate this, I've seen libraries create a service that during App Initialization will essentially wire up scripts by appending to document body some CDN paths.

In our case, we end up deploying npm-install scripts in the packages that has to search, then modify, these sections of the angular application. While scaffolding exists, its extremely heavy duty for what is essentially a json merge of these sections from library and application.