angular - compat - rxjs pipe map

En rxjs angulares, ¿cuándo debería usar `pipe` vs` map`

Question

Estoy un poco confundido por el operador de pipe frente al map encadenamiento. ¿Son los dos ejemplos siguientes funcionalmente equivalentes? ¿Cuál es el propósito o la ventaja de la función de tubería?

const name = ajax
  .getJSON<{ name: string }>("/api/employees/alice")
  .pipe(
    retry(3, 1000),
    map(employee => employee.name),
    catchError(error => of(null))
  );

const name = ajax
  .getJSON<{ name: string }>("/api/employees/alice")
  .let(retry(3, 1000))
  .map(employee => employee.name)
  .catch(error => Rx.Observable.of(null));

Answer 1

La "nueva" forma, usando pipe , se llama Operadores de Lettable Operadores Pipeable . La forma "antigua", donde se llaman operadores de cadena, se llama usando "operadores de parche".

A partir de la versión 5.5, hemos enviado "operadores de pipeable", a los que se puede acceder en rxjs/operators (observe los "operadores" pluralizados). Estos están destinados a ser un mejor enfoque para atraer a los operadores que necesita que los operadores "parche" que se encuentran en rxjs/add/operator/* .

Hubo algunos problemas con los operadores de parches . También pueden garantizar que su paquete producido a partir de su código sea más pequeño. También hay otras ventajas, consulte la documentación que lo cubre bastante bien.

Para responder a su otra pregunta, aunque sus 2 muestras de código son funcionalmente equivalentes. También debe usar Operadores Pipeable sobre Operadores de Patch siempre que sea posible.

De la documentación ( para completar )

Los problemas con los operadores parcheados para dot-chaining son:

1. Cualquier biblioteca que importe un operador de parche aumentará el Observable.prototype para todos los consumidores de esa biblioteca, creando dependencias ocultas. Si la biblioteca elimina su uso, sin darse cuenta ellos rompen a todos los demás. Con pipetables, debe importar los operadores que necesita en cada archivo donde los usa.
2. Los operadores parcheados directamente en el prototipo no son "inestables" por herramientas como Rollup o Webpack. Los operadores con pipeta serán como son simplemente funciones extraídas directamente de los módulos.
3. Los operadores no utilizados que se importan en aplicaciones no se pueden detectar de manera confiable mediante ningún tipo de herramienta de construcción o regla de pelusa. Eso significa que puede importar scan , pero dejar de usarlo, y aún se está agregando a su paquete de salida. Con los operadores que se pueden pipetear, si no lo está usando, una regla de pelusa puede recogerlo por usted.
4. La composición funcional es asombrosa. Crear sus propios operadores personalizados se vuelve mucho, mucho más fácil, y ahora funcionan y se parecen a todos los demás operadores de rxjs. Ya no es necesario extender Observable ni anular la lift .