Observables natifs, RxRxnd l'observable qui n'existe pas encore

Beaucoup de choses intéressantes se produisent en ce moment.

RxJS 7 est génial, RxJS 8 est en alpha, il semble utilisable, tout comme les nouveaux Native Observables qui sont disponibles dans Chrome aujourd'hui !

Pouvons-nous les utiliser ensemble ?
Réponse courte, plutôt non. Techniquement, ils sont tous observables, ils devraient donc parler la même langue, n'est-ce pas ? C'est juste .subscribe, .next, .error, .complete, et voilà...

Eh bien, presque. Sauf que RxJS fait des efforts supplémentaires pour s'assurer qu'il s'agit de vrais Obsevables et non des "importations bon marché" ?.
Il vérifie donc avec diligence la présence de Symbol.observable ou @@observable, de sorte que vous pouvez techniquement les patcher dans le DOM Observable en faisant Observable.prototype['@@observable'] = function(){ return this }, mais ... même si vous réussissez et que vous parvenez à connecter les deux ensemble via document.when('click').subscribe(new Subject()), cela échouera à nouveau car les flux RxJS font des références aux leurs, this, en interne, qui pointera désormais ailleurs... donc ça casse.

Pas de chance, nous avons besoin d'un pont personnalisé qui s'abonne au Native Observable et transmet les données vers RxJS land.

Super, supposons que nous fassions ça, bien sûr, cela fonctionnerait. Vous seriez soudainement capable de faire quelque chose comme ce qui suit, à condition que cette fonction idiote soit terminée :

const clickCount = rx(
  wrap(document.when('click')),
  scan(x=>x+1, 0),
);

clickCount.subscribe(doSomething);

Quoi qu'il en soit, même si ce qui précède pourrait déjà être considéré comme une sorte de nouvelle, ce n'est pas du tout la partie vraiment intéressante pour l'instant !

La partie intéressante

La partie intéressante ici vient lorsque nous parlons de l'utilisation d'Observables dans le monde réel, dans des applications réelles, qui se trouvent généralement dans des frameworks Web ou des bibliothèques d'interface utilisateur plus petites.

Considérons le cas d'un bouton compteur de clics, utilisant des Observables, à l'intérieur d'un "Composant" JavaScript.

import { Subject, scan } from 'rxjs';
import { rml } from 'rimmel';

const Component = () => {
  const counter = new BehaviorSubject(0).pipe(
    scan(x=>x+1)
  );

  return rml`
    <button onclick="${counter}">hit me</button>
    Count: <span>${counter}</span>
  `;
}

Maintenant, avec Native DOM Observables, nous avons quelques problèmes intéressants. Le sujet n'existe pas, BehaviorSubject non plus.
En plus de cela, il n'a même pas de méthode .pipe() pour transmettre les opérateurs.
Enfin, ses opérateurs natifs sont toutes des méthodes de la classe Observable, pas des fonctions.

Alors, la grande question est : comment appelle-t-on les méthodes d'un objet qui... n'existe pas encore ?

(Vous êtes probablement perdu à ce stade... Je sais, attendez)

La nouvelle façon de créer des observables ressemble à element.when(eventName). C'est un appel natif au DOM.
Cependant, nous sommes maintenant dans un modèle, nous sommes dans un composant JavaScript. Aucun élément HTML n'a encore été ajouté au DOM, donc aucun appel à .when() n'aurait pu être effectué.

Et nous voulons appeler .map().inspect().filter() dessus !

Un oubli ? RxJS utilisait la même interface jusqu'à il y a quelques années (d'autres comme Bacon et Zen Observables le font toujours), mais pour faciliter le tremblement d'arbre, ils ont divisé toutes les méthodes d'opérateur en fonctions d'opérateur, vous pouvez désormais importer exactement ce dont vous avez besoin, rendant ainsi vos applications plus légères. Super !

L'Observatoire

Alors, revenons à notre nouvelle situation, comment résoudre ce problème à partir d'un composant ?
Bien sûr, eh bien, c'est facile ! Soit nous obtenons Subject et BehaviorSubject dans la proposition WICG (spoiler : pour l'instant, nous ne le faisons pas), soit... nous faisons preuve de créativité, piratons le système et concevons quelque chose comme un proxy qui nous aide à faire semblant que le Native DOM Observable est là, même si ce n'est pas le cas, nous pouvons donc appeler ses méthodes d'opérateur natives. ?

Je l'ai appelé... l'Observature.

Futur observable = Observation. Observaturus est le latin pour "celui qui observera", donc si nous forçons cela en anglais, cela devrait ressembler à ça.

Bien, alors à quoi tout cela ressemblerait-il dans le code ?

const clickCount = rx(
  wrap(document.when('click')),
  scan(x=>x+1, 0),
);

clickCount.subscribe(doSomething);

Ouais, regarde ça ! Nous avons quelque chose ici : new Observature(0).scan(x=>x 1).
Laissez-moi vous expliquer cela.
Techniquement, c'est comme créer un nouveau BehaviorSubject(0).scan(x=>x 1) sauf pour une chose : il n'y a plus de BehaviorSubject. ?
L'Observature n'est qu'un proxy. Il expose les méthodes d'Observable et d'Observer pour un abonnement ultérieur et une liaison ultérieure !
Si vous appelez .scan(fn), il se souviendra simplement d'appeler .scan sur l'observable auquel il sera abonné, le moment venu.

Alors, qu'est-ce que les Observatures apportent d'intéressant ?
Le premier est le fait qu'ils ne sont pas de véritables sujets, donc lorsque vous exécutez le code ci-dessus, la fonction d'opérateur que vous fournissez s'exécutera au niveau 1/2 dans la pile. Il pourrait être plus léger et plus rapide que tout ce que vous avez vu auparavant, du clic à l'évier. Non, je n'ai pas encore fait de benchmarks et cela ne me dérange pas, c'est le concept qui compte, pour l'instant.

Ah, encore une petite note. Il n'y a pas non plus d'Observable.scan() dans la spécification actuelle, donc une chose que nous pouvons faire est de patcher pour le moment, mais encore une fois, ce ne sont que de minuscules détails d'implémentation. Nous avons des Observables natifs, c'est le gros problème !

Pour rester 100 % natif, pour d'autres cas d'utilisation, vous pouvez simplement utiliser .map() et .filter(), mais d'après mon expérience, vous ne pouvez pas non plus vivre une vie convenable sans scan().

RxJS 8

Ok, donc... ce qui précède utilisait des éléments natifs, pas de RxJS.
À quoi cela ressemblerait-il avec RxJS8 ?
Ma réponse est je n'en ai aucune idée, demandez à @benlesh, c'est votre homme :)

Les obstacles actuels sont les mêmes : les Observables natifs ne sont pas reconnus par RxJS, il y a donc un peu de travail à faire. Tout pourrait ressembler à ceci :

import { Subject, scan } from 'rxjs';
import { rml } from 'rimmel';

const Component = () => {
  const counter = new BehaviorSubject(0).pipe(
    scan(x=>x+1)
  );

  return rml`
    <button onclick="${counter}">hit me</button>
    Count: <span>${counter}</span>
  `;
}

Qu'en pensez-vous ? Utiliseriez-vous quelque chose comme ça ?

Pour l'instant, vous pouvez jouer avec DOM Observables, Observatures sur ce Stackblitz

Envoyez un message pour laisser vos pensées.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!