fromWorker Subject creator be considered to be brought back to core

[lozandier]

Feature Request

Per a conversation over Google Hangouts w/ @benlesh, I was asked to file a ticket for fromWorker to be considered to come back since RxJS 5 (RxJS-DOM).

Is your feature request related to a problem? Please describe.
It's increasingly common for developers to separate work from the main thread using web workers more than ever. RxJS5 made it very convenient to hook a Web Worker to be an Observable to then subscribe to.

Web Worker API was standardized in a way for easy methods to subscribe to values over time as well as cleanly disposing the use of a Web Worker (webWorker.terminate()).

Without it out of the box like what Rxjs.DOM enabled for RxJS 5 in the past, it can become quite redundant & tedious to create an Observable based from a Web Worker script.

Describe the solution you'd like
fromWebWorker is available from rxjs or rxjs/fromWorker as a function that returns Subject<T>:

Example of it being made available

import { fromWorker, Subscription } from "rxjs" 

const worker$: Stream<number> = fromWorker<number>('some-worker-involving-numbers.js')

// number is already inferred as `number` from the expression above via TypeScript
const workerSubscription: Subscription = worker$.subscribe( number => console.log(`Number: ${number}`) );

worker$.next([2, 2]))

// Somewhere down the line the worker isn't needed
workerSubscription.unsubscribe();

Describe alternatives you've considered
Can't think of any besides its inclusion again

(If this is new operator request) describe reason it should be core operator
N/A

Additional context
@benlesh & I talked about it during a RXJS user group meeting and he liked it enough to instruct me to fill a ticket here.

[kwonoj]

I have discussed this in core meeting and I'm not in a huge favor of this, primarily there's no good semantics to deal with transferable. Given contract next doesn't have param other than value itself, 1. it is hard to specify which value to be transferred 2. since observable doesn't care about ownership of values, once value is transferred over subject's multicast will have confusion (i.e if one of subscriber decide to transfer value, what'll happen to other subscriber?). Also, since worker only accepts serializable object, which makes based on source observable subscriber chain may lose some of value unexpectedly. Also this'll make error propagation tricky, as error object is not seralizable.

in addition to those, there are minor things need to be clarified like how to construct worker (just specifying filename is not sufficient cause due to environment there are numbers of way to create worker).

I think libraries like comlink (https://github.com/GoogleChromeLabs/comlink) offers better solution to establishing worker communication, and observable can wrap those things easily instead (cause comlink offers promise, observable can interop easily)

Rxjs.DOM enabled for RxJS 5

btw did we have this for 5? not rxjs 4?

[lozandier]

@kwonoj Thanks for enlightening me about the difficulty adding back this Subject creator might bring to the codebase.

For some reason, I'm not familiar w/ comlink yet; I indeed may have to look into wrapping its functionality with an Observable. Outside the scope of this discussion, its documentation is sparse on various types of messages you'd want to receive & merely wrap over to next & subscribe over time vs. a particular object w/ methods & etc.

You may be completely correct regarding RxJS-DOM being used for 4 vs. 5; I can't recall.

[zakhenry]

@lozandier you may be interested in https://github.com/cloudnc/observable-webworker (disclosure, I'm the primary author).

This library's goals are specifically to provide support webworker flows with rxjs. Also coming soon is a feature to automatically manage worker pools. I kinda doubt this kind of thing belongs within rxjs itself, however I'd be more than willing to help merge it in if the rxjs team is keen.

[benlesh]

Has there been an user-land libraries for this that have been successful? I actually use workers a fair amount at my day job, but the code around it pre-dates me, and there's no RxJS, but there's a desire to get us there.

One thing I learned from WebSocketSubject though: The typings were a gaff. It needs two generics, In and Out or Send and Receive, because you might say, send objects in one shape, but get objects back in a completely different shape (or maybe even binary streams?)