Après avoir beaucoup lu sur Observables après être venu d'une grande application basée sur Promise, je comprends leur pouvoir d'utiliser des flux / modèles d'événements, cependant, j'ai l'impression qu'il y a des moments où l'utilisation d'Observables semble maladroite et exagérée.
Lorsque vous voulez récupérer des données, en particulier pour les données paginées, l'Observable est parfait. Vous pouvez câbler une taille initiale et un décalage pour la pagination et faire en sorte que les mises à jour de la page et de la taille déclenchent une mise à jour de l'observable et il récupère plus de données, les transforme, etc.
Cependant, lorsque nous le faisons quelque chose de simple comme une requête DELETE à / api / books / 123 et il n'y a pas de réponse valable, il est gênant d'utiliser Observables car il n'y a rien à "observer" et vous devez "déclencher" la requête pour être faite en y souscrivant.
Voici un exemple:
Promise
myService.DeleteBook('123')
// the book is still there as the request isn't sent yet
.subscribe(x => {
// finally in here the book is deleted, but 'x'
// is pretty much worthless so this method pretty much does nothing.
});
Observable
await myService.DeleteBook('123');
// the book is now deleted
Quelques choses me viennent donc à l'esprit:
wait de la ligne Tous les blogueurs et articles que je vois autour d'Observables semblent se concentrer sur l'utilisation d'Observables tout le temps et de ne jamais utiliser de Promises.
Ce type semblait être la seule personne à" se lever "pour Observables et a essayé d'expliquer pourquoi ils ne devraient être utilisés que lorsqu'ils ont du sens, mais tous les commentaires sont des gens qui le dénigrent et disent que les observables sont toujours la solution miracle.
Quelqu'un peut-il m'expliquer pourquoi là-bas est-ce une position si forte en faveur de l'utilisation d'Observables dans tous les cas?
3 Réponses :
J'aurais tendance à être d'accord avec vous, en particulier pour les cas d'utilisation ici, et même pour les GET. Pour Angular, j'aime le .toPromise():
let book = await httpObservableService.GetBook('123').toPromise()
Je vous remercie! C'est exactement ce que je pensais. Nous pouvons rendre tout observable à l'intérieur du service, mais le consommateur n'a pas vraiment besoin de tous les bagages supplémentaires fournis avec Observables. J'ai trouvé que googler semble être unilatéral dans cette discussion et je ne sais pas pourquoi
myService.DeleteBook('123')
// the book is still there as the request isn't sent yet
.subscribe(x => {
// finally in here the book is deleted, but 'x'
// is pretty much worthless so this method pretty much does nothing.
});
"x" is not totally worthless. You still want to check the response
and show success message accordingly or handle the HTTP error in the
error callback. Right? With promises, you will have to wrap it in to try/catch to handle the HTTP error.
The other best thing about observables is they can be combined with
other observables and chained. If you take a look at RXJS operators,
you can do some pretty cool stuff with them. It's the Operators that
makes fun to work with observables.
For example in your case, imagine there is a requirement to show
warning dialog before deleting. You can chain the delete observable
with the warning observable along with filter operator to only delete
if "Yes" was clicked by the user. This would be easier to accomplish
if you are using observables over promises.
Also for consistency reason, you want to keep the same subscribe
pattern everywhere. Like, you don't want to use Promise in one place
and observables in others to confuse other developers.
Les observables sont bien plus que ce que vous avez mentionné.
Il ne s'agit pas de streaming, ni de gestion des événements, ni même de composition, bien que tous ces facteurs importent.
Observable est une sorte de superpuissance de T : une fois que vous l'avez, vous ne pouvez pas revenir. Spiderman ne pourrait jamais devenir un simple Peter Parcker. En particulier, cela signifie que vous "soulevez" votre code régulier, ce qui lui donne une grande capacité à faire .. toutes les choses géniales que rx fait.
La meilleure façon de comprendre rx est de le considérer comme une fonction généralisée - celle qui peut faire une infinité de déclarations return au fil du temps. Essayez de vous débarrasser de cette sorte de nonse de vous débarrasser des .. fonctions elles-mêmes. Plutôt que d'essayer de vous en débarrasser, vous devez essayer d'y insérer votre solution exactement de la même manière que vous définissez votre solution abstraite en termes de certaines classes équipées de certaines fonctions de certaines signatures ou même des fonctions exportées à nu. Dans quelques cas, cela vous oblige à mapper quelque chose qui n'est pas (encore) observable (comme la promesse) à une observable sémantiquement égale ( from (...) le fait). Vous devez donc utiliser ces mappeurs librement et sans aucun doute.
Faites-moi savoir si des explications plus détaillées sont nécessaires.
Matt, si vous avez besoin de Promise concaténée, vous pouvez facilement devenir fou. Les observables peuvent enchaîner, fork, debounce, swichmap, ... (ce n'est qu'une opinion)