from(Subscribable) - Part Two

[kajetansw]

Hello all! 👋 I hope you're doing well.

I'd like to touch on a year-old RFC about from(Subscribable) support.

I know, at the time it seemed like there wasn't enough use-cases for it to make it happen, but please bear with me while add my two cents...

Reason

The reason I'm mentioning this, is that I really wished to use Observables in SolidJS where you have an observable method designed to convert Solid's signals to Observables.

Example of that:

import { observable } from "solid-js";
import { from } from "rxjs";

const [s, set] = createSignal(0);

// Creating Solid's observable from Solid signal
const solidObs$ = observable(s);

// Converting to RxJS observable
const rxObs$ = from(observable(s));

solidObs$.subscribe((v) => console.log(v));
rxObs$.subscribe((v) => console.log(v));

But there are some TS type errors when trying to do so, you can see it in action here: https://stackblitz.com/edit/solid-vite-ogtpkn?file=src/index.tsx

It seems like those two types (RxJS's ObservableInput and Observable's definition in SolidJS) are incompatible.

Observable's definition in SolidJS is the one that is in shape of "objects that have a subscribe() method", just like described in the previous RFC.

Solution?

I saw in the previous issue, that Subscribable was already considered to be added to a possible type for ObservableInput, like:

export type ObservableInput<T> =
  | Observable<T>
  | InteropObservable<T>
  | AsyncIterable<T>
  | PromiseLike<T>
  | ArrayLike<T>
  | Iterable<T>
  | ReadableStreamLike<T>
  | Subscribable<T>;

As it has the desirable shape already:

export interface Subscribable<T> {
  subscribe(observer: Partial<Observer<T>>): Unsubscribable;
}

And then the Observable be created with sth like:

export function fromSubscribable<T>(obj: any) {
  return new Observable((subscriber: Subscriber<T>) => {
    const obs = obj;
    if (isFunction(obs.subscribe)) {
      return obs.subscribe(subscriber);
    }
    // Should be caught by observable subscribe function error handling.
    throw new TypeError('Provided object does not correctly implement "subscribe" method');
  });
}

I find it very similar case to how the InteropObservable is already handled. Do you think so too?

Conclusion

I don't know if it's enough of a case or a simple addition to make, I just want to hear your opinion on that.

I'm sorry to bring this back from the dead and thanks in advance!