take (1) vs first ()

Ho trovato alcune implementazioni di AuthGuards che usano take(1). Nel mio progetto, ho usato first().

Entrambi funzionano allo stesso modo?

import 'rxjs/add/operator/map';
import 'rxjs/add/operator/first';
import { Observable } from 'rxjs/Observable';

import { Injectable } from '@angular/core';
import { CanActivate, Router, ActivatedRouteSnapshot, RouterStateSnapshot } from '@angular/router';
import { AngularFire } from 'angularfire2';

@Injectable()
export class AuthGuard implements CanActivate {

    constructor(private angularFire: AngularFire, private router: Router) { }

    canActivate(route: ActivatedRouteSnapshot, state: RouterStateSnapshot): Observable<boolean> | boolean {
        return this.angularFire.auth.map(
            (auth) =>  {
                if (auth) {
                    this.router.navigate(['/dashboard']);
                    return false;
                } else {
                    return true;
                }
            }
        ).first(); // Just change this to .take(1)
    }
}

Gli operatori first()e take(1)non sono gli stessi.

L' first()operatore accetta una predicatefunzione opzionale ed emette una errornotifica quando nessun valore corrisponde quando la fonte è stata completata.

Ad esempio, questo genererà un errore:

import { EMPTY, range } from 'rxjs';
import { first, take } from 'rxjs/operators';

EMPTY.pipe(
  first(),
).subscribe(console.log, err => console.log('Error', err));

... oltre a questo:

range(1, 5).pipe(
  first(val => val > 6),
).subscribe(console.log, err => console.log('Error', err));

Mentre questo corrisponderà al primo valore emesso:

range(1, 5).pipe(
  first(),
).subscribe(console.log, err => console.log('Error', err));

D'altra parte take(1)prende solo il primo valore e lo completa. Nessuna ulteriore logica è coinvolta.

range(1, 5).pipe(
  take(1),
).subscribe(console.log, err => console.log('Error', err));

Quindi con sorgente vuota osservabile non emetterà alcun errore:

EMPTY.pipe(
  take(1),
).subscribe(console.log, err => console.log('Error', err));

Gennaio 2019: aggiornato per RxJS 6

Suggerimento: utilizzare solo first()se:

• Consideri zero elementi emessi una condizione di errore (ad es. Completamento prima dell'emissione) E se c'è una probabilità di errore superiore allo 0%, la gestisci con grazia
• OPPURE Sai al 100% che la fonte osservabile emetterà 1+ oggetti (quindi non puoi mai lanciare) .

Se non vi sono emissioni zero e non la si sta gestendo esplicitamente (con catchError), allora l'errore verrà propagato, probabilmente causerà un problema imprevisto altrove e può essere abbastanza difficile da rintracciare, soprattutto se proviene da un utente finale.

Sei più sicuro usando take(1)per la maggior parte a condizione che:

• Stai bene take(1)non emettere nulla se la fonte viene completata senza emissione.
• Non è necessario utilizzare un predicato inline (ad es. first(x => x > 10))

Nota: è possibile utilizzare un predicato con take(1)come questo: .pipe( filter(x => x > 10), take(1) ). Non vi è alcun errore in questo caso se nulla è mai maggiore di 10.

Che dire single()

Se vuoi essere ancora più severo e non consentire due emissioni, puoi utilizzare single()quali errori se ci sono zero o 2+ emissioni . Ancora una volta avresti bisogno di gestire gli errori in quel caso.

Suggerimento: a Singlevolte può essere utile se vuoi assicurarti che la tua catena osservabile non stia facendo un lavoro extra come chiamare due volte un servizio http ed emettere due osservabili. L'aggiunta singlealla fine del tubo ti farà sapere se hai fatto un tale errore. Lo sto usando in un 'task runner' in cui passi un'attività osservabile che dovrebbe emettere un solo valore, quindi passo la risposta single(), catchError()per garantire un buon comportamento.

Perché non usare sempre first()invece di take(1)?

aka. Come può first potenzialmente causare più errori?

Se hai un osservabile che prende qualcosa da un servizio e poi lo convoglia, first()dovresti andare bene per la maggior parte del tempo. Ma se qualcuno arriva per disabilitare il servizio per qualsiasi motivo - e lo modifica per emettere of(null)o NEVERqualsiasi first()operatore a valle inizierebbe a lanciare errori.

Ora mi rendo conto che potrebbe essere esattamente quello che vuoi, quindi perché questo è solo un suggerimento. L'operatore firstmi ha fatto appello perché sembrava un po 'meno "goffo" rispetto a take(1)ma devi fare attenzione a gestire gli errori se c'è mai la possibilità che la fonte non emetta. Dipenderà interamente da quello che stai facendo però.

Se hai un valore predefinito (costante):

Considera anche .pipe(defaultIfEmpty(42), first())se hai un valore predefinito che dovrebbe essere usato se non viene emesso nulla. Questo ovviamente non genererebbe un errore perché firstriceverebbe sempre un valore.

Si noti che defaultIfEmptyviene attivato solo se il flusso è vuoto, non se il valore di ciò che viene emesso è null.

Qui ci sono tre osservabili A, Be Ccon i diagrammi di marmo per esplorare la differenza tra first, takee singlegli operatori:

* Legenda : errore di
--o-- valore
----!
----| completamento

Gioca con esso su https://thinkrx.io/rxjs/first-vs-take-vs-single/ .

Avendo già tutte le risposte, volevo aggiungere una spiegazione più visiva

Spero che aiuti qualcuno

C'è una differenza davvero importante che non è menzionata da nessuna parte.

take (1) emette 1, completa, annulla l'iscrizione

first () emette 1, completa, ma non annulla l'iscrizione.

Significa che il tuo osservabile a monte sarà ancora caldo dopo first () che probabilmente non è un comportamento previsto.

UPD: si riferisce a RxJS 5.2.0. Questo problema potrebbe essere già stato risolto.

Sembra che in RxJS 5.2.0 l' .first()operatore abbia un bug ,

A causa di quel bug .take(1)e .first()può comportarsi in modo abbastanza diverso se li stai usando con switchMap:

Con take(1)te otterrai il comportamento come previsto:

var x = Rx.Observable.interval(1000)
   .do( x=> console.log("One"))
   .take(1)
   .switchMap(x => Rx.Observable.interval(1000))
   .do( x=> console.log("Two"))
   .subscribe((x) => {})

// In the console you will see:
// One
// Two
// Two
// Two
// Two
// etc...

Ma con .first()te otterrai un comportamento sbagliato:

var x = Rx.Observable.interval(1000)
  .do( x=> console.log("One"))
  .first()
  .switchMap(x => Rx.Observable.interval(1000))
  .do( x=> console.log("Two"))
  .subscribe((x) => {})

// In console you will see:
// One
// One
// Two
// One
// Two
// One
// etc... 

Ecco un link per codepen