2017-06-02 1 views
-1

Ein wenig Pseudo-Code unten vorbei, den Titel zu erklären:RxJs ursprüngliche Ereignis innerhalb abonnieren immer ohne

Subject source = new Subject(); 

    function sendInNewResource(newNumber, anotherVariable) { 
     source.next(newNumber); 
    } 

    const newSource = source 
    .map((myNumber) => myNumber++); 

    newSource.subscribe((data) => { 
     //How can I access myObject here? 
    }); 

    sendInNewResource(1, {myObject}); 

Ich denke, die Pseudo-Code ein wenig von dem, was erklärt, was ich tun möchte. Bis jetzt habe ich versucht, das Observable zu erweitern, aber wenn ich das tat, sieht es so aus, als müsste ich die Operatoren innerhalb des Observablen überschreiben.

Ich möchte fast Metadaten zum Ereignis bereitstellen.

Ich möchte nicht das myObject übergeben, da dies eine Bibliothek für den externen Gebrauch ist, werde ich die Observables innerhalb meiner Codebasis abonnieren, aber Verkettung der beobachtbaren wird extern erfolgen.

Wer hat irgendwelche Ideen, wie man das erreicht?

Für Kontext, Ich versuche, eine rein RxJs http Bibliothek zu erstellen, die mir erlauben wird, wie folgt vorgehen:

const server$ = RxHttpServer(server) 

const api$ = server.filter((request) => request.url.startsWith('/api')); 

const apiEndpoint$ = api.map(() => ({ 
    status: 400, 
    body: 'this is an api endpoint', 
    headers: { 
    } 
})); 

// Inside my library, note the use of the response object that I don't have access to: 
apiEndpoint.subscribe((dataToSend) => response.write(dataToSend)) 

die innere Logik und Handhabung dieser Objekte wurde bereits geschrieben, nur müssen das Antwortobjekt, an das zurückgesendet werden soll.

+0

Mein Wissen in RxJS ist begrenzt, aber, müssen Sie myObject nicht als Parameter an die nächste übergeben? 'source.next (newNumber, myObject)' Wenn das nicht möglich ist, könntest du ein Argument dekonstruieren 'source.next ({newNumber, myObject})'. – Baruch

+0

@Baruch, das ist die eine Sache, die ich mit diesem Beitrag zu vermeiden versuche, da ich nicht möchte, dass Benutzer des Frameworks die Antwort für jede Kette, die sie machen, weiterleiten müssen. Wenn Sie sich vorstellen, dass ein Endpunkt einen anderen Endpunkt über eine Flatmap aufruft, haben Sie sofort die Antwort verloren oder müssten die Selektorfunktion überall verwenden, was die Benutzerfreundlichkeit ein wenig ruiniert. –

+0

Würden Sie das "response" -Objekt einschließen? Sie brauchen in einer beobachtbaren? In diesem Fall können Sie sowohl 'apiEndpoint $' als auch 'response $' zusammen "kombinieren" und dann auf diese 2 im Callback zugreifen. – atomrc

Antwort

0

Sie könnten einen responseFor Helper verwenden, der die Antwortmetadaten übernehmen und eine beobachtbare Antwortantwort zurückgeben würde, eine für jede HTTP-Anforderung. Der Bibliotheksbenutzer kann sie abonnieren und Daten für jeden Antwortbetreff schreiben. Während Sie in der Bibliothek den gleichen Antwortsubjekt abonnieren und an den Client zurücksenden können, wenn dieser abgeschlossen ist. So etwas wie:

+0

Vielleicht verstehe ich nicht, was Sie richtig meinen, aber ein Thema von Typ Antwort würde nicht wirklich funktionieren als - wenn wir eine Anfrage haben, die 2 Sekunden dauert, um zu antworten und eine weitere Anfrage, die sofort behandelt werden kann, die erste (Langsame Anfrage) wird von der zweiten Observablen behandelt. Noch einmal, vielleicht bekomme ich das völlig falsch, was würde die responseFor-Methode tun? :) –

+0

Es hängt davon ab, was der 'apiEndpoint $' Beobachter tut. Wenn Sie langsam sind, müssen Sie einen anderen asynchronen Anruf tätigen und die Antwort danach abschließen. Der Async-Aufruf wird geplant, JavaScript kehrt sofort vom Code des ersten Beobachters zurück und der nächste Beobachter wird bedient. Wenn langsam die tatsächliche Berechnung ist, blockiert der erste Beobachter und die zweite wird nicht bedient. Aber das ist immer ein Problem mit Javascript Singlethread. Sie benötigen eine plattformspezifische Art der Parallelität, dh Sie können den Verarbeitungscode in einen Web Worker einbinden. –

+0

Eine andere Sache, die Sie tun können, ist das Anrufen von 'responseSubject.observeOn (Rx.scheduler.async)' auf jedem Antwortobjekt. Dadurch wird sichergestellt, dass Benutzer, die response.next (data) ausführen, nicht synchron ausgeführt werden und anderen Beobachtern Zeit zur Verarbeitung geben. Wenn jedoch die Berechnung zum Berechnen von "Daten" synchron und lang ist (wie ein Schlaf im Code), wird der Haupt-JavaScript-Thread immer noch blockiert. –

Verwandte Themen