Add Symbol.observable to docs

[dy]

Hi!
I just found out I've implemented same thing with minimal footprint for spect: value-ref.
Going to add your package to readme.

The only thing I'd propose elaborating in readme here - add mention of Symbol.observable method, that it actually conforms the proposal. It would be cool because it allows interop with other libs/packages, like hyperf, templize, subscribable-things, rxjs etc.

[medikoo]

Hi @dy, great thanks for opening that. Indeed https://github.com/spectjs/value-ref looks very similar, great to see other minds thinking alike :)

Concerning Symbol.observable and ECMAScript proposal. I think it's an attempt to standardize the concept of Observable from rxjs, which I've always seen as something different, that approached similar problem from a bit different angle

Do you think it makes sense to merge both interfaces? Also AFAIK ES proposal is dead, and it's very unlikely it'll become as standard at any point.

[dy]

.subscribe(onnext, onerror?, oncomplete?) appears to me very minimal and logical pattern regardless of proposal and rxjs (which I'm not a huge fan of). The pattern is needed and reappears in ecosystem everywhere, too bad it's non-normative and has many variations. Same situation used to be with Promises, there's even any-promise package.

I see Symbol.observable a reasonable common ground for interop. It got some tracking with subscribable-things, zen-observable, spect and others (prob I should collect more examples - not vue, unfortunately). It's also logical - regardless of proposal. It doesn't pollute namespace, which is nice 0-overhead and can extend any reactive objects not imposing itself. It doesn't require unsubscribe action, if properly done via weakrefs. And it's minimal. It can even be done implicitly without special mention, just as indicator of reactivity - similar to what you've done but with actual connector.

What are the alternatives then?

• keeping situation as is, with multiple varying implementations.
• Symbol.asyncIterable - which is async, less trivial to implement, and has pull-style streaming.
• .on('change') - which is good and minimal, but implies arbitrary non-lifecycle events, also implies manual disposal of listeners. It doesn't act also as indicator of reactivity.

[Symbol.observable] () {
  return {
    subscribe: (next, err, done) => (
      this.on('change', next),
      { unsubscribe: () => this.off('change', next) }
    )
  }
}
// that would be even cooler if `Symbol.observable` returned directly `subscribe` function that returns directly `unsubscribe`, without that props overhead.

[dy]

I mean, I wish to at least have universal reactive subscribe adapter in sube, but some implementations don't have apparent indicator of reactivity, eg. .on is not sufficient.

[medikoo]

.subscribe(onnext, onerror?, oncomplete?) appears to me very minimal and logical pattern regardless of proposal and rxjs

@dy thanks for the clarifications, still in use cases I was addressing with this package I didn't find this pattern compelling.

Technically we may agree that this package expresses a different approach on how to handle reactivity, and trying to switch here to a different idea, doesn't make much sense.

Currently Symbol.observable is nowhere near standard (nothing close to what promises are), but if at some point situation will change, I will definitely revisit, and at least add some comment here.

Also, note that this package is not really evaluated and used at this point. It was extensively used a few years back in some projects I engineered, and maybe it'll become revitalized in the future, but for now, we can consider it's in suspension.

[dy]

Too sad. Symbol.observable, as well as rxjs and zen-observable have 50mil downloads weekly, as well as longstanding proposal. If that's too far from the standard I wonder what is not too far then. Vast adoption would push specifiers, but everyone is just doing their own thing. Bummer.