Eine Einführung in Observables und wie sie sich von Versprechungen unterscheiden

' Observables ', ' Observables ', ' Observables ' ... Ja! Heute werden wir über dieses oft diskutierte Wort des Marktes sprechen. Wir werden auch erfahren, wie sie sich von Versprechungen unterscheiden (haben noch nichts von Versprechungen gehört? Keine Sorge! Sie werden bald mehr wissen). Lasst uns beginnen!

Ich bin zum ersten Mal auf den Begriff Observable gestoßen, als ich anfing, Angular zu lernen. Obwohl es sich nicht um eine winkelspezifische Funktion handelt, handelt es sich um eine neue Art der HandhabungasynchronAnfragen. Asynchrone Anfrage? Du weißt es, richtig? Nein! Es ist in Ordnung. Lassen Sie uns zunächst verstehen, was eine asynchrone Anforderung ist.

Asynchrone Anfragen

Gut! Sie müssen über asynchrone Funktionen in der JavaScript-Welt gelesen haben. ' Asynchronität ' in der Computerwelt bedeutet, dass der Programmfluss unabhängig erfolgt. Es wartet nicht darauf, dass eine Aufgabe erledigt wird. Es geht zur nächsten Aufgabe über.

Jetzt denken Sie vielleicht - was passiert mit der Aufgabe, die noch nicht erledigt ist? Der Mitarbeiter erledigt diese nicht erledigten Aufgaben. Ja! Im Hintergrund arbeitet und erledigt ein Mitarbeiter diese noch nicht erledigten Aufgaben. Sobald sie erledigt sind, sendet er Daten zurück.

Dies kann eine weitere Frage aufwerfen, wie wir mit den zurückgegebenen Daten umgehen. Die Antwort lautet Versprechen , Observables , Rückrufe und vieles mehr.

Wir wissen, dass diese asynchronen Operationen Antworten zurückgeben, entweder einige Daten nach Erfolg oder einen Fehler. Um dies zu bewältigen, kamen Konzepte wie Versprechen , Rückrufe und Observable auf den Markt. Gut! Ich werde jetzt nicht darauf eingehen , da wir von unserem Unterthema, der " asynchronen " Anfrage, abgewichen sind . (Keine Sorge! Diese Themen werden in Kürze besprochen.)

Nachdem Sie die oben genannten Punkte besprochen haben, haben Sie möglicherweise ein grobes Bild von der asynchronen Anforderung. Lassen Sie es uns klären. Bei einer asynchronen Anforderung wartet der Client nicht auf die Antwort. Nichts ist blockiert. Lassen Sie uns dieses Konzept anhand eines sehr häufigen Szenarios verstehen.

In der Web-Welt ist es durchaus üblich, auf den Server zuzugreifen, um Daten wie die Details eines Benutzers, eine Liste usw. abzurufen. Wir wissen, dass es einige Zeit dauern wird und alles folgen kann (Erfolg / Misserfolg).

In diesem Fall warten wir nicht auf das Eintreffen von Daten, sondern asynchron (kein Warten), damit unsere Anwendung nicht blockiert wird. Solche Anforderungen sind asynchrone Anforderungen. Ich denke jetzt sind wir klar damit. Lassen Sie uns sehen, wie wir diese asynchronen Anforderungen tatsächlich verarbeiten können.

Wie ich Ihnen bereits sagte, hat Observables uns eine neue Möglichkeit gegeben, asynchrone Anfragen zu bearbeiten. Die anderen Möglichkeiten sind Versprechen, Rückrufe und Async / Warten. Dies sind die beliebtesten Wege. Schauen wir uns zwei davon an, die Rückrufe und Versprechen sind.

Rückrufe

Rückrufe sind weit verbreitet. Rückruffunktionen (wie der Name schon sagt) werden auf der Rückseite aufgerufen. Wenn die Anforderung abgeschlossen ist und die Daten oder Fehler zurückgibt, werden diese Funktionen aufgerufen. Schauen Sie sich den Code zum besseren Verständnis an:

const request = require(‘request’); request('//www.example.com', function (err, response, body) { if(error){ // Error handling } else { // Success } });

Dies ist eine Möglichkeit, eine asynchrone Anforderung zu verarbeiten. Aber was passiert, wenn wir nach dem Erfolg der ersten Anfrage erneut Daten an den Server anfordern möchten? Was ist, wenn wir nach dieser erfolgreichen zweiten Anfrage eine dritte Anfrage stellen möchten? Schrecklich!

Zu diesem Zeitpunkt wird unser Code unordentlich und weniger lesbar. Dies nennt man " Rückruf Hölle ". Um es zu überwinden, kamen Versprechen. Sie bieten eine bessere Möglichkeit, eine asynchrone Anforderung zu verarbeiten, die die Lesbarkeit des Codes verbessert. Lassen Sie uns ein bisschen mehr verstehen.

Versprechen

Versprechen sind Objekte, die versprechen, dass sie in naher Zukunft einen Wert haben werden - entweder ein Erfolg oder ein Misserfolg. Versprechen haben ihre eigenen Methodendann und fangen . .then () wird aufgerufen, wenn der Erfolg eintritt , andernfalls wird die Methode catch () aufgerufen .  Versprechenwerden mit dem Versprechen Konstruktor erstellt. Schauen Sie sich den Code an, um ihn besser zu verstehen.

function myAsyncFunction(name){ return new Promise(function(resolve, reject){ if(name == ‘Anchal’){ resolve(‘Here is Anchal’) } else{ reject(‘Oops! This is not Anchal’) } } } myAsyncFunction(‘Anchal’) .then(function(val){ // Logic after success console.log(val) // output - ‘Here is Anchal’ }) .catch(function(val){ //Logic after failure console.log(val) // output - ‘Oops! This is not Anchal’ })

Wie Sie sehen können, verspricht myAsyncFunction tatsächlich, dass es in naher Zukunft einen gewissen Wert haben wird. .then () oder .catch () wird entsprechend dem Status des Versprechens aufgerufen.

Versprechen verbessern die Lesbarkeit des Codes . Sie können anhand von Versprechungen sehen, wie lesbar der Code ist. Mit Promises kann eine bessere Handhabung von asynchronen Vorgängen erreicht werden. Dies ist eine kurze Einführung, was Versprechen sind, wie sie mit Daten umgehen und welche Schönheitsversprechen enthalten sind.

Jetzt ist es Zeit, mehr über unser Hauptthema zu erfahren: Observables.

Was sind Observablen?

Observables sind auch wie Rückrufe und Versprechen, die für die Bearbeitung asynchroner Anforderungen verantwortlich sind. Observables sind Teil der RXJS- Bibliothek. Diese Bibliothek führte Observables ein.

Bevor Sie verstehen, was ein Observable tatsächlich ist, müssen Sie zwei Kommunikationsmodelle verstehen: Ziehen und Drücken . Diese beiden Konzepte sind Protokolle darüber, wie Datenproduzenten mit den Datenkonsumenten kommunizieren.

Pull & Push-Modell

Wie ich Ihnen bereits sagte, sind Push und Pull Kommunikationsprotokolle zwischen Datenproduzenten und -konsumenten. Lassen Sie uns beide einzeln verstehen.

Ziehen Modell: In diesem Modell der Verbraucher von Daten ist König . Dies bedeutet, dass der Datenkonsument bestimmt, wann er Daten vom Produzenten möchte. Der Hersteller entscheidet nicht, wann die Daten geliefert werden. Sie können besser verstehen, wenn Sie Funktionen damit verknüpfen .

Wie wir wissen, sind Funktionen für die Ausführung einer Aufgabe verantwortlich. Beispielsweise ist dataProducer eine Funktion, die einfach eine Zeichenfolge wie " Hi Observable " zurückgibt .

function dataProducer(){ return ‘Hi Observable’; }

Jetzt können Sie sehen, dass die obige Funktion nicht entscheiden wird, wann die Zeichenfolge 'Hi Observable' geliefert wird. Es wird vom Verbraucher entschieden, das ist Code, der diese Funktion aufruft. Verbraucher ist König. Der Grund, warum es als Pull-Modell bezeichnet wird, ist, dass die Pull- Aufgabe die Kommunikation bestimmt. Das istdasModell ziehen . Gehen wir nun zum Push- Modell .

Push - Modell: In diesem Modell der Produzent von Daten ist König . Der Hersteller bestimmt, wann Daten an den Verbraucher gesendet werden sollen. Der Verbraucher weiß nicht, wann Daten kommen werden. Lassen Sie es uns anhand eines Beispiels verstehen:

Ich hoffe du erinnerst dich an Versprechen . Ja, Versprechen folgen dem Push- Modell .  Ein Versprechen (Produzent) liefert Daten an den Rückruf ( .then () - Verbraucher). Rückrufe wissen nicht, wann Daten kommen werden. Hier ist Versprechen (Produzent) König. Es bestimmt die Kommunikation. Deshalb heißt es Push Model, da der Produzent verantwortlich ist.

Like promises, Observables also follow the push model. How? You will get the answer once I elaborate on observables. Let’s get back to observables then.

Observables as functions

To simply understand, you can think of observables as functions. Let’s have a look at the below examples:

function dataProducer(){ return ‘Hi Observable’ } var result = dataProducer(); console.log(result) // output - ‘Hi Observable’ 

You can get the same behaviour using an observable:

var observable = Rx.Observable.create((observer: any) =>{ observer.next(‘Hi Observable’); }) observable.subscribe((data)=>{ console.log(data); // output - ‘Hi Observable’ })

From above, you can see both functions and observables show the same behaviour. This may bring a question to your mind - are observables the same as functions? No. I'll clarify in a minute why the answer is no. Have a look at an elaborate version of the above example.

function dataProducer(){ return ‘Hi Observable’; return ‘Am I understandable?’ // not a executable code. } var observable = Rx.Observable.create((observer: any) =>{ observer.next(‘Hi Observable’); observer.next( ‘Am I understandable?’ ); }) observable.subscribe((data)=>{ console.log(data); }) Output : ‘Hi Observable’ ‘Am I understandable?’ 

I hope you can now see what difference I wanted to address. From above, you can see,both functions and observables are lazy. We need to call (functions) or subscribe (observables) to get the results.

Subscriptions to observables are quite similar to calling a function. But where observables are different is in their ability to return multiplevalues called streams (a stream is a sequence of data over time).

Observables not only able to return a value synchronously, but also asynchronously.

var observable = Rx.Observable.create((observer: any) =>{ observer.next(‘Hi Observable’); setTimeout(()=>{ observer.next(‘Yes, somehow understandable!’) }, 1000) observer.next( ‘Am I understandable?’ ); }) output : ‘Hi Observable’ ‘Am I understandable?’ Yes, somehow understandable!’. 

In short, you can say observables are simply a function that are able to give multiple values over time, either synchronously or asynchronously.

You now have an outline about observables. But let’s understand them more by looking into different phases of observables.

Observable Phases

We have already seen from the above example how observables create and execute and come into play by subscription. Hence, there are four stages through which observables pass. They are:

  1. Creation
  2. Subscription.
  3. Execution
  4. Destruction.

Creation of an observableis done using a createfunction.

var observable = Rx.Observable.create((observer: any) =>{ }) 

To make an observablework, we have to subscribe it. This can be done using the subscribe method.

observable.subscribe((data)=>{ console.log(data); })

Execution of observables is what is inside of the create block. Let me illustrate with the help of an example:

var observable = Rx.Observable.create((observer: any) =>{ observer.next(‘Hi Observable’); setTimeout(()=>{ observer.next(‘Yes, somehow understandable!’) }, 1000) observer.next( ‘Am I understandable?’ ); }) 

The above code inside the create function is observable execution. The three types of values that an observable can deliver to the subscriber are:

observer.next(‘hii’);//this can be multiple (more than one) observer.error(‘error occurs’) // this call whenever any error occus. Observer.complete(‘completion of delivery of all values’) // this tells the subscriptions to observable is completed. No delivery is going to take place after this statement.

Let’s have a look below to understand all three values:

var observable = Rx.Observable.create((observer: any) =>{ try { observer.next(‘Hi Observable’); setTimeout(()=>{ observer.next(‘Yes, somehow understandable!’) }, 1000) observer.next( ‘Am I understandable?’ ); observer.complete(); observer.next(‘lAST DELIVERY?’ ); // above block is not going to execute as completion notification is already sent. } catch(err){ observer.error(err); } }) 

Last phase that comes into the market is destruction. After an error or a complete notification, the observable is automatically unsubscribed. But there are cases where we have to manually unsubscribe it. To manually do this task, just use:

var subscription = observable.subscribe(x => console.log(x)); // Later: subscription.unsubscribe();

This is all about the different phases through which an observable passes.

I think, now, we know what observables are? But what about the other question which is - how observables are different from promises? Let’s find the answer to it.

Promises vs observables

As we know, promises are for handling async requests and observables can also do the same. But where do they differ?

Observables are lazy whereas promises are not

This is pretty self-explanatory: observables are lazy, that is we have to subscribe observables to get the results. In the case of promises, they execute immediately.

Observables handle multiple values unlike promises

Promises can only provide a single value whereas observables can give you multiple values.

Observables are cancelable

You can cancel observables by unsubscribing it using the unsubscribe method whereas promises don’t have such a feature.

Observables provide many operators

There are many operators like map, forEach, filter etc. Observables provide these whereas promises does not have any operators in their bucket.

These are features that makes observables different from promises.

Now, it's time to end. I hope you have a better understanding of the hot topic of observables!

Thanks for reading!