Heim >Web-Frontend >js-Tutorial >Native Observables, RxRxnd das Observable, das noch nicht existiert

Native Observables, RxRxnd das Observable, das noch nicht existiert

Patricia Arquette
Patricia ArquetteOriginal
2024-12-29 05:37:18673Durchsuche

Native Observables, RxRxnd the observable that doesn

Im Moment passieren viele interessante Dinge.

RxJS 7 rockt, RxJS 8 ist in der Alpha-Phase, es scheint verwendbar zu sein, und das gilt auch für die neuen Native Observables, die heute in Chrome verfügbar sind!

Können wir sie zusammen verwenden?
Kurze Antwort, eher nein. Technisch gesehen sind sie alle Observablen, sollten also die gleiche Sprache sprechen, oder? Es ist einfach .subscribe, .next, .error, .complete und voilà...

Na ja, fast. Außer, dass RxJS zusätzliche Anstrengungen unternimmt, um sicherzustellen, dass es sich um echte Obsevables handelt und nicht um „billige Importe“?.
Daher wird sorgfältig geprüft, ob Symbol.observable oder @@observable vorhanden ist. Sie könnten diese also technisch in das DOM-Observable einbauen, indem Sie Observable.prototype['@@observable'] = function(){ return this } ausführen, aber ... selbst wenn Sie Erfolg haben und es schaffen, beide über document.when('click').subscribe(new Subject()) miteinander zu verbinden, wird es erneut fehlschlagen, weil RxJS-Streams auf ihr eigenes this verweisen, intern, was jetzt woanders hinzeigt... also geht es kaputt.

Pech, wir brauchen eine benutzerdefinierte Brücke, die das Native Observable abonniert und Daten an RxJS-Land weiterleitet.

Großartig, wenn wir das machen würden, würde es sicher funktionieren. Plötzlich könnten Sie so etwas wie Folgendes tun, vorausgesetzt, Sie haben diese Wrap-Silly-Funktion erledigt:

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

clickCount.subscribe(doSomething);

Obwohl das Obige bereits als eine Art Neuigkeit gelten könnte, ist es noch nicht der wirklich interessante Teil!

Der interessante Teil

Der interessante Teil hier kommt, wenn wir über die Verwendung von Observables in der realen Welt sprechen, in realen Anwendungen, die sich normalerweise in Web-Frameworks oder kleineren UI-Bibliotheken befinden.

Stellen Sie sich den Fall einer Klickzähler-Schaltfläche vor, die Observables innerhalb einer JavaScript-„Komponente“ verwendet.

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

Nun haben wir mit Native DOM Observables ein paar interessante Probleme. Betreff existiert nicht, BehaviorSubject auch nicht.
Darüber hinaus gibt es nicht einmal eine .pipe()-Methode zur Übergabe von Operatoren.
Schließlich sind seine nativen Operatoren alle Methoden der Observable-Klasse, keine Funktionen.

Die große Frage ist also: Wie nennt man die Methoden eines Objekts, das... noch nicht existiert?

(An diesem Punkt bist du wahrscheinlich verloren ... Ich weiß, warte)

Die neue Art, Observables zu erstellen, sieht wie element.when(eventName) aus. Es ist ein nativer Aufruf an das DOM.
Allerdings befinden wir uns jetzt in einer Vorlage, wir befinden uns in einer JavaScript-Komponente. Dem DOM wurde noch kein HTML hinzugefügt, sodass möglicherweise kein Aufruf von .when() erfolgen konnte.

Und wir wollen .map().inspect().filter() darauf aufrufen!

Ein Versehen? RxJS verfügte bis vor ein paar Jahren über dieselbe Schnittstelle (andere wie Bacon und Zen Observables tun dies immer noch), aber um das Tree-Shaking zu erleichtern, haben sie alle Operatormethoden in Operatorfunktionen, sodass Sie jetzt genau das importieren können, was Sie brauchen, und Ihre Apps leichter machen. Großartig!

Die Observatur

Also zurück zu unserer neuen Situation: Wie lösen wir das innerhalb einer Komponente?

Klar, das ist ganz einfach! Entweder erhalten wir „Subject“ und „BehaviorSubject“ im WICG-Vorschlag (Spoiler: Im Moment tun wir das nicht) oder ... wir werden kreativ, hacken das System und konzipieren so etwas wie einen Proxy, der uns hilft,
so zu tun, dass das Native DOM Observable ist vorhanden, auch wenn dies nicht der Fall ist, sodass wir seine nativen Operatormethoden aufrufen können. ?

Ich habe es...die Observatur genannt.

Beobachtbare Zukunft = Beobachtung.

Observaturus ist lateinisch und bedeutet „jemand, der beobachten wird“. Wenn wir das also ins Englische zwingen, sollte es ungefähr so ​​klingen.

Gut, wie würde das alles im Code aussehen?


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

clickCount.subscribe(doSomething);
Yay, schau dir das an! Wir haben hier etwas: new Observature(0).scan(x=>x 1).

Lassen Sie mich das erklären.
Technisch gesehen ist es so, als würde man ein neues BehaviorSubject(0).scan(x=>x 1) erstellen, außer einer Sache: Es gibt kein BehaviorSubject mehr. ?
Die Observatur ist nur ein Stellvertreter. Es stellt Methoden von Observable und Observer für ein späteres Abonnement und eine spätere Bindung bereit!
Wenn Sie .scan(fn) aufrufen, wird es sich nur daran erinnern, .scan auf dem tatsächlichen Observable aufzurufen, das es abonniert, wenn es soweit ist.

Welche interessanten Dinge bringen Observaturen mit sich?

Erstens handelt es sich nicht um tatsächliche Subjekte. Wenn Sie also den obigen Code ausführen, wird die von Ihnen bereitgestellte Operatorfunktion auf Ebene 1/2 im Stapel ausgeführt. Es könnte leichter und schneller sein als alles, was Sie bisher gesehen haben, vom Klick bis zum Sinken. Nein, ich habe noch keine Benchmarks durchgeführt und es stört mich nicht. Im Moment zählt nur das Konzept.

Ah, noch eine kleine Anmerkung. Es gibt derzeit auch kein Observable.scan() in der Spezifikation, daher können wir im Moment nur einen Monkey-Patch durchführen, aber das sind wiederum nur winzige Implementierungsdetails. Wir haben native Observables, das ist die große Sache!

Um 100 % nativ zu bleiben, können Sie für andere Anwendungsfälle einfach .map() und .filter() verwenden, aber meiner Erfahrung nach kann man ohne scan() auch kein richtiges Leben führen.

RxJS 8

Okay, also... oben wurde natives Zeug verwendet, kein RxJS.

Wie würde das alles mit RxJS8 aussehen?
Meine Antwort ist, ich habe keine Ahnung, frag @benlesh, er ist dein Mann :)

Die aktuellen Hindernisse sind die gleichen: Native Observables werden von RxJS nicht erkannt, es gibt also noch ein wenig Arbeit. Es könnte alles etwa so aussehen:


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>
  `;
}
Was denken Sie? Würden Sie so etwas verwenden?

Im Moment können Sie mit DOM Observables und Observatures auf diesem Stackblitz spielen

Schreiben Sie eine Nachricht, um Ihre Gedanken zu hinterlassen.

Das obige ist der detaillierte Inhalt vonNative Observables, RxRxnd das Observable, das noch nicht existiert. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn