Une introduction à Observables et en quoi ils sont différents des promesses

« Observables », « Observables », « Observables » ... Oui! Aujourd'hui, nous allons parler de ce mot souvent discuté du marché. Nous découvrirons également en quoi ils sont différents des Promises (vous n'avez pas entendu parler des Promises? Ne vous inquiétez pas! Vous en saurez plus bientôt) Commençons!

J'ai rencontré le terme Observable pour la première fois lorsque j'ai commencé à apprendre Angular. Bien que ce ne soit pas une fonctionnalité spécifique à Angular, c'est une nouvelle façon de gérerasynchronedemandes. Demande asynchrone? Vous le savez, non? Non! C'est bon. Voyons d'abord ce qu'est une requête asynchrone .

Demandes asynchrones

Bien! Vous devez avoir lu sur les fonctionnalités asynchrones dans le monde JavaScript. « Asynchronie » dans le monde informatique signifie que le flux du programme se produit indépendamment. Il n'attend pas qu'une tâche soit terminée. Il passe à la tâche suivante.

Maintenant, vous pensez peut-être - qu'arrive-t-il à la tâche qui n'est pas terminée? Le collègue gère ces tâches inachevées. Oui! En arrière-plan, un collègue travaille et gère ces tâches inachevées et une fois qu'elles sont terminées, il renvoie les données.

Cela peut soulever une autre question sur la façon dont nous traitons les données renvoyées. La réponse est des promesses , des observables , des rappels et bien d'autres.

Nous savons que ces opérations asynchrones renvoient des réponses, soit des données après succès, soit une erreur. Pour gérer cela, des concepts comme les promesses , les rappels , les observables sont arrivés sur le marché. Bien! Je ne les aborderai pas maintenant car nous nous sommes écartés de notre sous-sujet, à savoir la demande « asynchrone ». (Ne vous inquiétez pas! Ces sujets seront abordés prochainement).

Après avoir discuté des points ci-dessus, vous avez peut-être une idée approximative de ce qu'est la requête asynchrone . Clarifions les choses. Une demande Async est celle où le client n'attend pas la réponse. Rien n'est bloqué. Comprenons ce concept en regardant un scénario très courant.

Dans le monde du Web, il est assez courant de frapper le serveur pour obtenir des données telles que les détails d'un utilisateur, une liste, etc. Nous savons que cela prendra du temps et tout peut suivre (succès / échec).

dans ce cas, au lieu d'attendre l'arrivée des données, nous les traitons de manière asynchrone (pas d'attente) pour que notre application ne soit pas bloquée. Ces demandes sont des demandes asynchrones. Je pense que maintenant nous sommes clairs avec cela. Voyons donc comment nous pouvons réellement gérer ces requêtes asynchrones.

Comme je vous l'ai déjà dit, Observables nous a proposé une nouvelle façon de gérer les requêtes asynchrones. Les autres moyens sont les promesses, les rappels et async / await. Ce sont les moyens les plus populaires. Jetons un coup d'œil à deux d'entre eux qui sont des rappels et des promesses.

Rappels

Les rappels sont assez courants. Les fonctions de rappel (comme leur nom l'indique) sont appelées à l'arrière. C'est à ce moment que la demande est terminée et renvoie les données ou l'erreur, ces fonctions sont appelées. Jetez un œil au code pour une meilleure compréhension:

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

C'est une façon de gérer une requête asynchrone. Mais que se passe-t-il lorsque nous voulons à nouveau demander au serveur des données après le succès de la première demande? Et si nous voulons faire une troisième demande après cette deuxième demande réussie? Horrible!

À ce stade, notre code deviendra désordonné et moins lisible. Cela s'appelle «l' enfer des rappels ». Pour le surmonter, des promesses ont été faites. Ils offrent un meilleur moyen de gérer une requête asynchrone qui améliore la lisibilité du code. Comprenons un peu plus.

Promesses

Les promesses sont des objets qui promettent qu'elles auront de la valeur dans un proche avenir - soit un succès, soit un échec. Les promesses ont leurs propres méthodes qui sontpuis et attraper . .then () est appelé en cas de succès, sinon la méthode catch () appelle.  Promessessont créés à l'aide du constructeur de promesse . Jetez un œil au code pour mieux comprendre.

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

Comme vous pouvez le voir, myAsyncFunction promet en fait qu'il aura une certaine valeur dans un proche avenir. .then () ou .catch () est appelé en fonction du statut de la promesse.

Les promesses améliorent la lisibilité du code . Vous pouvez voir à quel point le code est lisible en utilisant des promesses. Une meilleure gestion des opérations asynchrones peut être obtenue à l'aide de Promises. Ceci est une brève introduction de ce que sont les promesses, comment elles traitent les données et ce que les promesses de beauté portent.

Maintenant, il est temps d'en apprendre davantage sur notre sujet principal: les observables.

Que sont les observables?

Les observables sont également comme des rappels et des promesses - qui sont responsables de la gestion des demandes asynchrones. Les observables font partie de la bibliothèque RXJS . Cette bibliothèque a introduit Observables.

Avant de comprendre ce qu'est réellement un observable, vous devez comprendre deux modèles de communication: tirer et pousser . Ces deux concepts sont des protocoles sur la manière dont les producteurs de données communiquent avec les consommateurs de données.

Modèle Pull & Push

Comme je vous l'ai déjà dit, Push and Pull sont des protocoles de communication entre producteurs et consommateurs de données. Comprenons les deux un par un.

Modèle Pull: Dans ce modèle, le consommateur de données est roi . Cela signifie que le consommateur de données détermine quand il veut des données du producteur. Le producteur ne décide pas du moment où les données seront livrées. Vous pouvez mieux comprendre si vous y associez des fonctions .

Comme nous le savons, les fonctions sont responsables de certaines tâches. Par exemple, dataProducer est une fonction qui renvoie simplement une chaîne, comme " Hi Observable ".

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

Maintenant, vous pouvez voir que la fonction ci-dessus ne décidera pas du moment où elle délivrera la chaîne «Hi Observable». Il décidera par le consommateur, c'est-à-dire le code qui appelle cette fonction. Le consommateur est roi. La raison pour laquelle on l'appelle un modèle d'extraction est que la tâche d' extraction détermine la communication. C'estlatirer le modèle . Passons maintenant au modèle Push .

Modèle Push: Dans ce modèle, le producteur de données est roi . Le producteur détermine quand envoyer les données au consommateur. Le consommateur ne sait pas quand les données vont arriver. Comprenons-le en prenant un exemple:

J'espère que vous vous souvenez des promesses . Oui, les promesses suivent le modèle push .  Une promesse (producteur) fournit des données au rappel ( .then () - consommateur). Les rappels ne savent pas quand les données vont arriver. Ici, la promesse (le producteur) est roi. Il détermine la communication. C'est pourquoi il s'appelle Push Model car le producteur est en charge.

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!