use truely functional pipeline

[xp44mm]

It is recommended to put the operator function in rxjs/operators with a suffix Observable and move up to the root space rxjs.

arrayAsObservable(candidates)
|> filterObservable(candidate => {
    const bg = candidate.experience.toLowerCase();
    return bg.includes('javascript') || bg.includes('c++');
  })
|> reduceObservable((acc, obj) => { 
    acc.push(obj.name);
    return acc;
    }, [])
|> subscribeObservable(console.log)

This enables a truely functional pipeline operation stream.

[voliva]

As far as I understood, this should work out-of-the-box with the current system.

What prevents you from doing the following?:

import { from } from 'rxjs';
import { map, filter, reduce } from 'rxjs/operators';

const languages = from(array)
  |> filter(value => {
    const bg = value.experience.toLowerCase();
    return bg.includes('javascript') || bg.includes('c++');
  })
  |> reduce((acc, obj) => { 
    acc.push(obj.name);
    return acc;
  }, [])

languages.subscribe(console.log);

I haven't tried, but as far as I can tell you don't need to suffix every function name with something so it can be piped, nor change the import path 🤔

BTW there's an issue that's already proposing moving all exports to the root rxjs #6242 but as I said I think it's unrelated to this.

[xp44mm]

your transpile result is all right!

With the popularity of functional programming, there may be many functions with similar names, zip, groupBy, If the suffix is omitted, the IDE does not know which library to import from . rxjs/operators or someArrayLibrary ? and the Observable suffix emphasizes that it returns a new Observable instance.

If there is no name conflict, the complex name space rxjs/operators is redundant.

[backbone87]

moving the operators to the top level namespace is on the agenda #6367

I don't like suffixing every operator with "Observable" to make them "more unique". typescript is actually quite smart nowadays and puts autocompletes with non-fitting types further down the list. you could also open a ticket in TS to even improve this behavior further, since it does not work every time.

[xp44mm]

Some snippets may be in help documentation or in books, relying on context, for example import statement, to determine the meaning of a statement is not a good idea. This adds complexity to typescript, and leads to some subtle bugs.

[backbone87]

you can always do import * as rxjsOps from 'rxjs/operators'; in code and use a conventional namespace for documentation/books. i understand your point, but I don't think it's a strong enough case to change the naming of ~80% of the exports of a library that is used in millions of projects -- just unrealistic.

[xp44mm]

Each function is considered separately, there is conflict, semantically ambiguous can be renamed, there is no conflict, semantic clear can remain unchanged. for example, from, sould change to promiseToObservable or arrayToObservable, because any type can have a from creator. but subscribe can no changed. becasuse it means subscription less conflict with other library.

[kwonoj]

First, as shared there is #6367 to improve ergonomics.

Secondly, I do not believe core team will pursue renaming all api surfaces to distinguish rxjs's api surface to other functional libraries. Separately, there are individual api surface level discussions to improve naming and it is current goal for immediate roadmaps for core team for viable future.