Skip to content

Move core operators onto Observable directly #468

Closed

Description

@benlesh

As an aside to the discussion on #464 ... We might want to move all core operators directly onto the Observable itself.

I'm on the fence about this one.

  1. It makes overriding operators for better performance on Observables like ScalarObservable and ArrayObservable more straightforward, and require less type checking in the operator implementations themselves.
  2. It's less hacky. We'll no longer be mutating the prototype in a separate module from Observable for our main operators
  3. It's unlikely most people will want to use an Observable with no operators.

... but I'll really want to trim down what is "core". For example, share() and multicast() should be core, since share is very commonly used, and multicast enables all other variants... but shareReplay, shareBehavior, publish, publishReplay, publishBehavior should probably not be "built in", IMO.

Activity

  1. benlesh commented on Oct 6, 2015

    @benlesh
    MemberAuthor
  2. staltz commented on Oct 7, 2015

    @staltz
    Member

    There is no point keeping share and leaving out shareReplay, shareBehavior, they are all equal specializations of multicast. Better just keep multicast.

    • If it can be done trivially with an existing operator or two, it's not core.
    • if it cannot be done trivially with an existing operator, it should be considered for core.

    share === multicast(() => new Rx.Subject()) looks trivial, so share is not core (?).

  3. benlesh commented on Oct 7, 2015

    @benlesh
    MemberAuthor

    they are all equal specializations

    I guess I'm unconvinced that they're as commonly used, even if they are very similar.

  4. staltz commented on Oct 7, 2015

    @staltz
    Member

    In Cycle.js world, definitely. In other contexts, I don't really know how RxJS is used in Netflix, neither in Angular2.

  5. jeffbcross commented on Oct 8, 2015

    @jeffbcross
    Contributor

    I don't really know how RxJS is used in Netflix, neither in Angular2.

    Neither do I! Actually, we right now only publish observables for component events, and for http requests. We don't consume them internally, except for in our examples. But the lighter the "core" set of operators can be, the better, as discussed in this issue.

  6. benlesh commented on Oct 8, 2015

    @benlesh
    MemberAuthor
  7. robwormald commented on Oct 12, 2015

    @robwormald
    Contributor

    In Typescript and with generated type definitions, the way the prototype is currently mutated doesn't complain internally, but also doesn't offer autocomplete or anything useful, which is sort of a bummer when y'all are making all this effort with Typescript and tooling.

    screen shot 2015-10-11 at 10 56 44 pm

  8. benlesh commented on Oct 12, 2015

    @benlesh
    MemberAuthor

    Yeah, we'll probably have to go back to at least adding stubs for every operator on the Observable type. It's just so ugly.

    Part of me wonders if it might be better just to switch to ES6 and manually maintain the .d.ts files...

  9. david-driscoll commented on Nov 16, 2015

    @david-driscoll
    Member

    I've done some work to that effect, that makes consuming the typings easier, and all the stubs only have to go into the operators themselves.

    #715

  10. benlesh commented on Nov 30, 2015

    @benlesh
    MemberAuthor

    I think we've decided not to do this.

  11. locked as resolved and limited conversation to collaborators on Jun 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions