All geek questions in one place

Javascript Reactive Programming

I'm new to reactive programming, and I lost a little reading all of these articles, which I cannot understand.

Actually, I am a javascript developer from Nodejs, Angularjs, Angular 2 and React.

What am I doing

I use promises all the time, for remote data retrieval, local async resolution, etc ... Better testing ability than callbacks that fit my needs.

What I understand using streams

I can’t understand where the threads can save me, except in a specific case.

This particular case is that I cannot use promises while listening to streams, because the promise will be resolved only once.

SocketIo example:

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

If I am not mistaken, I can use reactive flows to control this case, simply returning the observable. Right?

What? I do not understand

I am learning Angular 2 and all around. In fact, of the many blogs people use to use observational data to retrieve deleted data, and I cannot figure out what might be the advantage of using it instead of promises.

The fact is that I needed to do the remote, as in both cases, so why more than the other? Is this a performance issue?

What I need

If you read the whole question, I need to understand what are the advantages of using reactive programming instead of promises in case of remote data fetching?

In what (other cases) would it be better to use reactive material than ordinary material?

+5
source share
2 answers

@ Gunter gave you the basics of observables, especially the ability of promises to be called.

To go a little further, I believe that the key advantage of the observables is the ability to create an asynchronous data stream / stream using operators.

Here are some specific use cases:

  • debounceTime / switchMap . If you want to use form input to filter the list based on the corresponding HTTP requests, the value you need to use for the request is the one when the user has finished writing. No need to send multiple requests: one for new characters (one for 's', one for 'so', one for 'som', ..., one for 'something to search for'). The debounceTime statement allows this by buffering events and provides the latter after some time of inactivity.

    Here is an example:

     @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; }); } }

    If you use only switchMap , you will have one login request, but previous execution requests will be canceled. This allows you to get the correct result, especially if the query execution time is longer for some queries.

    In this case, you can associate the event with a web interface (DOM events) with HTTP requests to execute accordingly (respond to events) and apply some advanced behaviors.

  • To retry. By mixing retryWhen , delay and timeout statements, you can easily (and transparently) perform retries

     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); }

I think this is the real power of the observables: an asynchronous chain / data stream and binding various parts of the application based on events. This is something that cannot be done with promises and allows you to implement use cases to make your application more reliable.

Here is a series of articles that can give you more details:

+6
source

Basically, if you have one asynchronous event about which you do not want to be notified (callback), you use Promise . If you expect Observable be used in a series of events

Benefits of Observable over Promise

  • Observable can be canceled
  • Observables are lazy (don't do anything before signing up)
  • An observable can do what Promise can use, but only using Observable allows you to encode the same path (using rx operators instead of .then() regardless of whether you expect one or a series of events.
+3
source

Source: https://habr.com/ru/post/1244994/

More articles:


All Articles