`observableOf` and `observableFrom` instead of `of` and `from`

Issues

• People have strong feelings
• IDEs like to color of in error
• People that aren’t used to RxJS don’t know what of(1, 2, 3) means

Proposal

Rename of and from to observableOf and observableFrom.

Pros

• It’s less ambiguous and more explicit what code is doing
• IDEs are happier about it
• can make the change gradually without breaking everyone with an alias and a deprecation

Cons

• It’s WAY more verbose and makes code a bit more annoying to read.
• It’s another change to the library.
• Most people using RxJS a lot in their apps know what of and from mean

Other thoughts

• People can already to this with import aliases. `import { of as observableOf } from ‘rxjs’; and the five extra characters there probably isn’t going to kill them.
• It might actually encourage the use of Arrays as return values (which is totally fine) inside of mergeMap et al: source$.pipe(mergeMap(() => of(1, 2, 3))) is the same as source$.pipe(mergeMap(() => [1, 2, 3])). The readability of this versus of is debatable.
• observableFrom is probably the more annoying of the two changes, as it would be used more often to convert a promise ahead of other operators inside of flattening operators.

[alex-okrushko]

@Airblader to take the guessing out of the equation here are the results:

import { Component, Input } from '@angular/core';
import * as observable from 'rxjs';
import {take} from 'rxjs/operators';

@Component({
  selector: 'hello',
  template: `<h1>Inteval at {{interval | async}}!</h1>`,
  styles: [`h1 { font-family: Lato; }`]
})
export class HelloComponent  {
  interval = observable.interval(1000).pipe(take(10));
}

Before I added the take operator and interval here how it looked after ng build --prod --build-optimizer --source-map --eval-source-map

There are some operators, but those are using by Angular itself.

Here is after I added interval to the above mentioned Component:

As you can see even though import * as observable from 'rxjs'; was used only interval appeared in the optimized code.

I think this should resolve it.

[ajcrites]

I am personally in favor of not removing operators (unless there is a collision), so I wouldn’t want the rename. Doing import * as rx or import { of as rxOf } and the like are simple and acceptable alternatives that will keep the existing library more backwards compatible.