Discuss module structure for 6.0

Issue

Currently users need to import operators and observable creation method methods from a variety of places and it’s not always consistent or ergonomic.

import { merge } from 'rxjs/observable/merge';
import { concat } from 'rxjs/observable/concat';
import { timer } from 'rxjs/observable/timer';
import { map, filter, scan } from 'rxjs/operators';

Questions

What is the most ergonomic?

Do we want to try to shoot for an import process like import { map, filter, Observable, Subject, asyncScheduler } from 'rxjs'?

Do we want to keep things mostly the same for now?

How will this affect bundling?

What about node and Electron folks?

Options

1. Import everything from rxjs.
   • pro: Convenient and ergonomic.
   • con: We’d need to differentiate between static creation functions and operators of the same name (merge and merge might need to be mergeStatic or fromMerge and merge)

      import { merge, fromMerge, map, filter, Observable, Subject } from 'rxjs';
   

2. Import all static creation methods and observable types from rxjs, import operators from rxjs/operators.
   • pro:merge and merge can keep their names.
   • pro: We don’t have to move the operators.
   • con: two different locations to import from
3. Import observable types from rxjs observable creation methods from rxjs/observable and operators from rxjs/operators
   • pro: We don’t have to move the operators
   • con: three different locations to import from

… in all cases we should probably still provide the ability to “deep import” operators and the like, as some bundlers still stink at tree-shaking re-export modules.

[jayphelps]

My preference would be to do away with the lettable forms of operators which have a static equivalent. I imagine this would be quite controversial though… (many of you probably prefer the other form)

import { timer, race, map } from 'rxjs';

const items = race(
  timer(100) |> map(x => x * 100),
  timer(10) |> map(x => x * 10)
);

import { of, concat, map } from 'rxjs';

const items = concat(
  of(1, 2, 3) |> map(x => x * 100),
  of(4, 5, 6) |> map(x => x * 10)
);

I used to use the prototype-based forms (e.g. first.concat(second)) but recently I’ve settled on always using the static forms as I’ve found them more far self-explanatory for others reading my code later who may not be as familiar with Rx.

This would reduce the API surface and likely remove a confusion point for some. But it comes at the obvious cost of being less flexible, and perhaps more importantly deviating from some of the other Rx implementations in other languages…though not all of them have the instance variant, and RxJava/RxGroovy call it concatWith. We could call it that, but that doesn’t solve the other static operators and I don’t personally like it because it has a type signature mismatch with the other -With operator, startWith, which accepts a scalar not an Observable.

---

Alternatively, there could be two buckets, rxjs/observables and rxjs/operators and when there is a naming conflict the dev has to choose what alias they want to call them.

import { of, concat as concatStatic } from 'rxjs/observables';
import { concat, map } from 'rxjs/operators';

const items = concatStatic(
  of(1, 2, 3) |> map(x => x * 100),
  of(4, 5, 6) |> map(x => x * 10) |> concat(items)
);

In practice I don’t think this will happen often–why would someone want to use both forms of them? I’m guessing the answer is “because sometimes it feels better to use one or the other”

[benlesh]

This is done.