Nativescript: Rename {N} Observable to avoid confusion with standard rxjs Observable.

[NathanWalker]

RxJS is not just used with Angular implementations. It is used across many different types of JavaScript projects, has become a standard, is rich in features, and is familiar to many.

The {N} Observable class causes much confusion to {N} newcomers because of this.

The only place I've encountered them is when dealing with view bindings/view model files (there may be others).

We would love to get away from the this.set('property', value); necessity.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[NathanWalker]

Other Ref: https://github.com/NativeScript/NativeScript/issues/1289

[NathanaelA]

To be honest; I would think it would be better to see how easily it would be to actually replace the observable code base with RxJS so there is only one event/observable system in {N} and/or Angular {N}.

In addition to answer your last question @NathanWalker, you can use the new built in ES6 stuff like RxJS does to observe changes and proxy changes to things, and then eliminate any manual sets... Both device engines I believe support ES6 almost fully.

[NathanWalker]

I agree with @NathanaelA I feel like an effort to swap all observable and event stream code with standard RxJS would be worth the effort. It would definitely be some work but well worth it.

[hdeshev]

I'm all for renaming {N} Observable to TNSEventSource. I'm not sure about this replace thing though. Do we have to change all View objects (those are observable) into RxJS observables? How will the API look like?

---

Thinking out loud here...

There's also the problem of program size. RxJS is a fat library, and in order to use it effectively, we'd need to have everybody use webpack in their project. I'm not sure we are ready for that yet.

We also need performance tests for change events and binding updates...

[NathanaelA]

@hdeshev - Agreed I think a lot of benchmarks need to be done. This might be a non-starter depending on the benchmarks! If RXJS adds any real overhead, then I would only encourage the renaming. ;-)

My idea is basically it subsumes the behavior so that the rest of the code base really doesn't change; even if we have to add a couple minor monkey patches to RXJS to make it drop in compatible. Technically you create a new data/observable.js & OArray.js file that requires RXJS and exposes RXJS's Observable as the normal Observable. So the rest of the code base just works, but we get the full power of RXJS.

As for size; you are correct, it adds another meg of size; so I would agree WebPack would be important, but isn't WebPack supposed to be a high priority already?

[NathanWalker]

@hdeshev Curious to revitalize this discussion - In regards to swapping data/Observable with Rxjs - sizable and enormous task? Yes. Worth it?

RxJS observables are very different than the built-in NativeScript observables, and supporting those for the vanilla databound controls may be tricky. Anyway we may consider adding support, if there is enough interest in using RxJS sans Angular.

Is there enough interest?

[NickIliev]

^^^ @vakrilov @manoldonev @MartoYankov @ADjenkov @sis0k0 @vchimev

@NathanWalker just FYI: @hdeshev is not part of the NativeScript team.

[larssn]

RxJS is certainly modular now (since v6), so size shouldn't be an issue; even without tree shaking.