Vorteil der funktionalen reaktiven Programmierung über Event-Listener

7

Ich habe viel über funktionales reaktives Programmieren gehört und beschlossen, herauszufinden, was das große Problem ist. Wenn ich die speck.js-Dokumentation durchführe, scheint der Hauptunterschied darin zu bestehen, dass ich anstelle eines Event-Listeners für eine Komponente einen Event-Stream erzeuge und stattdessen den Event-Handler in den Stream übergebe. Mit anderen Worten, alles, was ich wirklich tat, war, den Event-Handler von der Komponente in den Event-Stream zu verschieben. Ist es das? Wenn ja, was ist der große Vorteil dabei?

    
tldr 24.05.2014, 18:12
quelle

2 Antworten

6
  

Ist es das?

Nein. Es geht um Ereignisströme . Am Ende werden Sie noch einen Listener an sie anhängen, um Effekte auszuführen, aber zwischen der Quelle und dem Ziel haben Sie eine sehr mächtige Abstraktion.

  

Was ist der große Vorteil, dies zu tun?

Die Ereignisströme haben viele Funktionen höherer Ordnung , um mit ihnen leicht umgehen zu können Komponieren sie, ohne den fehlerhaften Boilerplate-Code auszugeben.

Als die Docs haben es ziemlich gut gesagt, Speck

  

verwandelt Ihre Event Spaghetti in clean und deklarativen Feng Shui Bacon, indem Sie von Imperativ zu Functional wechseln. Es ist so, als würde man verschachtelte for -Schlaufen durch funktionale Programmierkonzepte wie map und filter ersetzen. Hören Sie auf, an einzelnen Ereignissen zu arbeiten, und arbeiten Sie stattdessen mit Ereignisströmen. Kombiniere deine Daten mit merge und combine [und wehre] schwerere Waffen [wie] flatMap und combineTemplate .

    
Bergi 24.05.2014, 19:02
quelle
12

Der Schlüsselpunkt zur funktionalen reaktiven Programmierung (FRP) ist eine syntaktische Eigenschaft:

  

Das dynamische Verhalten eines Werts wird bei Deklarationszeit angegeben.

Betrachten Sie beispielsweise einen Zähler, der durch Drücken einer Taste hoch- oder heruntergezählt werden kann. In einem imperativen Stil würden Sie es wahrscheinlich so schreiben:

%Vor%

Zuerst wird der Zähler mit einem Anfangswert deklariert. In späteren Teilen des Codes ändern Sie dann den Wert. Wenn Ihnen nun jemand die Frage stellt: "Zu irgendeinem Zeitpunkt, was ist der Wert von counter ?", Müssen Sie sich alle Teile des Codes anschauen, die auf den Namen counter verweisen, da dies der Fall ist geändert werden.

Im Gegensatz dazu kann die Frage bei der Verwendung von FRP-Stil-Code beantwortet werden, indem genau eine Stelle im Code betrachtet wird: die Stelle, an der counter deklariert wird. Zum Beispiel können Sie in Haskell den Zähler als

schreiben %Vor%

Die rechte Seite enthält alle Informationen, die Sie wissen müssen, was der Wert von counter zu einem bestimmten Zeitpunkt ist. Insbesondere sehen Sie, dass es Änderungen durch buttonUp und buttonDown , und das ist es sein kann. Sie müssen Ihren Code nicht durchsehen und nach Orten suchen, an denen sich der Zähler ändern könnte. Nein, es genügt, sich die Deklaration anzusehen und von dort aus weiterzumachen.

Dies ist der Grund, warum FRP-Code weniger fehleranfällig ist als ereignisbasierter Spaghetti-Code.

Siehe auch einige vorläufige Dokumentation für meine Dreipenny-gui-Bibliothek .

    
Heinrich Apfelmus 25.05.2014 07:46
quelle