Programmazione reattiva con Javascript

Question

Sono nuovo nella programmazione reattiva e ho perso un po 'la lettura di tutti questi articoli che non riesco a capire.

In realtà, sono uno sviluppatore javascript di Nodejs, Angularjs, Angular 2 e React.

Quello che faccio

Io uso le promesse per tutto il tempo, per il recupero remoto dei dati, la risoluzione asincrona locale ecc ... Meglio testabilità di callback e adatta alle mie esigenze.

Quello che ho capito utilizzando flussi

non riesco a capire dove i flussi mi può salvare, tranne in un caso particolare.

Questo caso speciale è che non posso utilizzare le promesse mentre ascolto su streaming perché la promessa sarebbe stata risolta una sola volta.

Un esempio con SocketIo:

io.on('connection', (socket) => { 
    // this works 
}); 

io.on('connection').then((socket) => { 
    // this can't work, promise would be resolved only once 
}); 

Se non sbaglio, ho potuto utilizzare i flussi reattivi per gestire questo caso, semplicemente la restituzione di un osservabile. Destra ?

Quello che non capisco

I m studiare angolare 2 e tutte le cose intorno. In realtà, da molti blog, le persone usano l'osservabile per recuperare i dati remoti e non riesco a capire quale potrebbe essere un vantaggio usarlo invece delle promesse.

Il fatto è che avrei dovuto creare un telecomando come in entrambi i casi, quindi perché più uno rispetto all'altro? È un problema di prestazioni?

Che cosa ho bisogno

Se avete letto l'intera questione, quello che mi serve è capire quali sono i vantaggi di usare programmazione reattiva, invece di promesse in caso di recupero dei dati a distanza?

In quali (altri casi) potrebbe essere meglio utilizzare materiale reattivo rispetto alle solite cose?

Answer 1

Fondamentalmente se si dispone di un singolo evento asincrono che non si desidera ricevere una notifica (callback) si utilizza uno Promise. Se vi aspettate una serie di eventi utilizzano Observable

Vantaggi di Observable oltre Promise

• osservabile può essere annullato
• osservabili sono pigro (non fare nulla prima di essere sottoscritto)
• lattina Osservabile fare ciò che Promise può ma usando solo Observable consente di codificare allo stesso modo (utilizzando gli operatori rx invece di .then() non importa se si prevede uno o una serie di eventi.

Answer 2

@ Günter ha fornito le basi degli osservabili, in particolare la capacità delle promesse di essere chiamate.

Per andare un po 'oltre, penso che il vantaggio chiave degli osservabili sia la possibilità di costruire un flusso/flusso di dati asincroni usando gli operatori.

Ecco alcuni casi di utilizzo concreti:

• debounceTime/switchMap. Quando si desidera sfruttare un modulo di input per filtrare un elenco in base alle richieste HTTP corrispondenti, il valore che è necessario utilizzare per la richiesta è quello che l'utente ha terminato di scrivere. Non è necessario inviare più richieste: una per ogni nuovo personaggio (uno per 's', uno per 'so', uno per 'som', ..., uno per 'qualcosa da cercare'). L'operatore debounceTime consente il buffering degli eventi e fornisce l'ultimo dopo un periodo di inattività.

  Ecco un esempio:

  @Component({ 
      (...) 
      template: ` 
      <input [ngFormControl]="ctrl"/> 
      ` 
  }) 
  export class MyComponent { 
      constructor() { 
      this.ctrl = new Control(); 
      this.ctrl.valueChanges 
         .debounceTime(500) 
         .distinctUntilChanged() 
         .switchMap((vallue: string) => { 
         // Get data according to the filled value 
         return this.service.getData(entry); 
         }) 
         .subscribe(data => { 
         // Update the linked list 
         this.list = data; 
         }); 
      } 
  } 
  

  Se si utilizza solo switchMap, si avrà una sola richiesta per ogni ingresso, ma precedente in corso saranno annullate le richieste. Ciò consente di ottenere il risultato corretto, soprattutto se i tempi di esecuzione delle richieste sono più lunghi per alcune richieste.

  In questo caso, è possibile collegare l'evento dall'interfaccia utente Web (eventi DOM) alle richieste HTTP per eseguire di conseguenza (reagire sugli eventi) e applicare alcuni comportamenti avanzati.

• Attendere riprovare. Mescolando retryWhen, delay e timeout operatori, si può facilmente (e trasparente) attuare tentativi

  searchPlaces(searchText:string) { 
      var params = new URLSearchParams(); 
      params.set('placename_startsWith', searchText); 
      params.set('username', 'templth'); 
  
      return this.http.get('http://api.geonames.org/postalCodeSearchJSON', 
       { search: params }) 
      .retryWhen(error => error.delay(500)) 
      .timeout(2000, return new Error('delay exceeded')) 
      .map(res => res.json().postalCodes); 
  } 
  

Credo che questo è il vero potere di osservabili: la catena di elaborazione asincrona/flusso di dati e collegato parti differenti dell'applicazione in base agli eventi. È qualcosa che non può essere fatto con promesse e consentire di implementare casi d'uso per rendere più robusta la tua applicazione.

Ecco una serie di articoli che potrebbero darvi maggiori dettagli:

• https://jaxenter.com/reactive-programming-http-and-angular-2-124560.html
• http://slides.com/robwormald/everything-is-a-stream
• https://gist.github.com/staltz/868e7e9bc2a7b8c1f754