This ideas portal has been deprecated. To submit new feature requests, please follow this guideline

Rename {N} Observable to avoid confusion with standard RxJS Observable

Rxjs has become a standard familiar to many. People often get confused why {N} has its own version which is nothing like the standard rxjs observable they are used to.

Where possible, it would be great to use rxjs for any event stream implementations throughout the codebase to join the friendly neighborhood built around rxjs. 

Rely less on proprietary custom implementations.

  • Nathan Walker
  • Nov 30 2016
Link to GitHub issue
  • Attach files
  • jianlei huang commented
    November 30, 2016 08:35

    we like pure Rxjs

  • Hristo Deshev commented
    November 30, 2016 09:09

    The {N} Observable class is a totally different beast than RxJS observables. The former is an object that raises (mostly) property change events, while the latter is an event stream implementation.


    We should probably rename the {N} Observable to something else to avoid confusion. How about `EventSource`? Of course, that could cause confusion with the W3 server-side events spec:

  • steve greensill commented
    November 30, 2016 10:32

    Thanks for this - I was asking myself this question yesterday...

  • Benjamin Lesh commented
    November 30, 2016 18:09

    Just rename yours. There's room for both. If you need help with interop, hit me up on Twitter. ❤️

  • Nathan Walker commented
    November 30, 2016 18:30

    The only place I've encountered them is when dealing with view bindings/view model files (there may be other cases). But in the event they are primarily focused on view model implementations, I would take into consideration the community has largely adopted a prefix for NativeScript specific classes, therefore my vote for rename:


    Then view models would be updated to:

    export class ViewModel extends TNSEventSource {
    // could still use this.set('property', value);

    However, we would all love to get away from the `this.set('property', value);` necessity.

    Hristo, could you think of a way that TNSEventSource could auto detect property changes from ` = value` removing the need for the `set` semantics?


  • Nathan Walker commented
    February 17, 2017 19:27

    I think instead of TNSEventSource, some other name - I like using `TNS` for community plugins to ensure they avoid confusion with other potential similar names on native platforms, but for internal class names from the framework, the `TNS` prefix is probably silly. But some other name rather than `Observable` would be great.