En quoi la programmation réactive est-elle différente de la programmation événementielle?
J'apprends la programmation réactive et la programmation réactive fonctionnelle en JavaScript. Je suis très confus.
Wikipedia dit qu'il existe différentes façons d'écrire du code réactif comme impératif, OORP et fonctionnel. Je veux savoir si l'événementiel est juste une autre façon d'écrire du code réactif?
Comment la programmation réactive est-elle liée aux promesses? Je pense que les promesses sont une alternative à l'enfer événementiel et de rappel.
Comment la programmation réactive est-elle liée à Promises? Je pense que la promesse est une alternative à l'enfer événementiel et de rappel.
Dans la pratique, les deux sont liés, j'aime appeler Promises un médicament de passerelle vers la programmation réactive fonctionnelle.
+----------------------+--------+-------------+
| | Sync | Async |
+----------------------+--------+-------------+
| Single value or null | Option | Promise |
| Multiple values | List | EventStream |
+----------------------+--------+-------------+
Les promesses peuvent être considérées comme des événements EventStreams avec un seul article, ou vous pouvez considérer les événements EventStreams comme plusieurs promesses au fil du temps.
Les promesses peuvent être enchaînées, ce qui se rapproche de la programmation réactive:
getUser() // return promise
.then((userId) => {
return fetch("/users/"+userId)
})
.then((user) => {
alert("Fetched user: " + user.name)
})
La même chose avec bacon.js:
const userStream = userIdStream // EventStream of userIds
.flatMapLatest((userId) => {
return Bacon.fromPromise(fetch("/users/"+userId))
})
const userNameStream = userStream.map((user) => user.name)
userNameStream.onValue((user) => {
alert("Fetched user: " + user.name)
})
Les deux extraits de code font la même chose, mais il y a une grande différence de pensée: avec les promesses, vous pensez à gérer une seule action avec des étapes asynchrones de manière claire - la pensée est impérative, vous faites les choses étape par étape. Avec FRP, vous dites "un flux de noms d'utilisateurs est créé à partir du flux de userIds en appliquant ces deux étapes de transformation". Lorsque vous avez un flux de noms d'utilisateur, sans se soucier d'où ils viennent, et dites "chaque fois qu'il y a un nouveau nom d'utilisateur, affichez-le à l'utilisateur".
Le style de codage FRP vous guidera pour modéliser votre problème sous forme de flux de valeurs (c'est-à-dire des valeurs qui changent au fil du temps) et les relations entre ces valeurs. Si vous connaissez déjà Promises, la courbe d'apprentissage initiale sera un peu plus facile, mais le principal avantage n'est obtenu que lorsque vous commencez à penser et à modéliser le problème différemment - il est possible (si ce n'est pas très utile) de faire une programmation impérative avec les bibliothèques FRP.
En quoi la programmation réactive est-elle différente de la programmation événementielle?
La programmation basée sur les événements tourne autour des soi-disant événements, qui sont des choses abstraites que les programmes "déclenchent" quand quelque chose se produit. D'autres endroits dans votre code "écoutent" les événements et répondent avec ce qu'ils doivent faire lorsque cet événement se produit. Par exemple, un événement peut être "l'utilisateur a appuyé sur ce bouton" ou "l'imprimante a fini d'imprimer votre document".
La programmation réactive traite des données . En fin de compte, il s'agit d'un cas particulier de programmation événementielle. L'événement: les données ont changé. Le gestionnaire d'événements: modifiez quelques données supplémentaires (le cas échéant). Ce concept est généralement clarifié lorsque vous pensez à une feuille de calcul. Si vous définissez cell1 = cell2 + cell3, Cela définit implicitement deux gestionnaires d'événements sur les événements de données modifiées de cell2 Et cell3 Pour mettre à jour les données de cell1. Les données de cell1 N'ont pas un tel gestionnaire d'événements, car aucune cellule ne dépend de sa valeur.
TL; DR;
Wikipedia dit qu'il existe différentes façons d'écrire du code réactif comme impératif, OORP et fonctionnel. Je veux savoir si l'événementiel est juste une autre façon d'écrire du code réactif?
L'idée de la programmation événementielle est orthogonale à l'idée d'impératif vs OO vs fonctionnel.
- Programmation impérative : se concentre sur le changement de l'état de votre programme pour atteindre ce que vous voulez. La plupart des ordinateurs sont impératifs (par opposition à programmation déclarative ), tandis que les langages de niveau supérieur sont parfois déclaratifs. La programmation déclarative, en revanche, traite de l'écriture de code qui spécifie ce que vous voulez qu'il fasse plutôt que COMMENT vous voulez que le code le fasse.
- [~ # ~] o [~ # ~] bject [~ # ~] o [ ~ # ~] programmation orientée : traite des soi-disant objets, ou des sacs de données avec des méthodes associées. Diffère de la programmation fonctionnelle car les méthodes sont capables d'accéder aux données associées aux objets.
- Programmation fonctionnelle : traite des fonctions réutilisables, ou des procédures qui prennent des entrées et des sorties. Cela diffère de la programmation OO car les fonctions n'ont traditionnellement pas la possibilité d'associer des données à une fonction autre que les entrées et les sorties.
Programmation événementielle : structure votre programme afin de gérer ("gérer") quelque chose d'autre qui se passe dans votre programme (un "événement"). En d'autres termes, il structure logiquement votre code comme ceci
When Event1 happens
do A and B
When Event2 happens
do B and C
Mais il existe de nombreuses façons d'écrire ce code, et en fait de nombreuses façons d'écrire le code impérativement, de nombreuses façons de l'écrire de manière fonctionnelle, etc. Voici cependant quelques exemples.
Impérativement (avec une boucle d'événement):
while(true)
// some other code that you need to do...
if Event1 then
do A
do B
if Event2 then
do B
do C
Orienté objet (avec fil de fond):
// event queue
events = new EventQueue()
handler = new EventHandler()
// creates background thread
Thread.DoInBackground(handler.listenForEvents(events))
// ... other code ...
// fire an event!
events.enqueue(new Event1())
// other file
class EventHandler
Func listenForEvents(events)
while(true)
while events.count > 0
newEvent = event.dequeue()
this.handleEvent(newEvent)
Thread.Sleep(Time.Seconds(1))
Func handleEvent(event)
if event is Event1
this.A()
this.B()
if event is Event2
this.B()
this.C()
Func A()
// do stuff
return
Func B()
// do stuff
return
Func C()
// do stuff
return
Fonctionnel (avec prise en charge linguistique des événements)
on Event(1) do Event1Handler()
on Event(2) do Event2Handler()
Func Event1Handler()
do A()
do B()
Func Event2Handler()
do B()
do C()
Func A()
// do stuff
return
Func B()
// do stuff
return
Func C()
// do stuff
return
// ... some other code ...
// fire! ... some languages support features like this, and others have
// libraries with APIs that look a lot like this.
fire Event(1)
Comment la programmation réactive est-elle liée à Promises?
Les promesses sont une abstraction du flux d'exécution du programme qui peut se résumer comme suit:
- Demandeur: Chaque fois que vous avez fini de faire ce que vous faites, me rappelez-vous?
- Answerer: Bien sûr, je promets
Rien de vraiment spécial ici, sauf que c'est une autre façon de penser à l'ordre dans lequel votre code est exécuté. Par exemple, les promesses sont utiles lorsque vous appelez une machine distante. Avec des promesses, vous pouvez dire "rappelez-moi lorsque vous revenez de cet appel à distance!". Quelle que soit la bibliothèque que vous utilisez, promet de vous rappeler lorsqu'elle récupère quelque chose de la machine distante. Souvent, cela est utile car il vous permet de faire autre chose en attendant sans attendre le retour de l'appel.
Punch line: il existe de nombreux styles de code différents, mais ils ne jouent pas un rôle trop important dans le modèle de programmation pilotée par les événements et réactive. À ma connaissance, vous pouvez faire de la programmation événementielle et/ou réactive dans la plupart des langages.
La programmation réactive est tout au sujet des flux, il peut s'agir de flux d'événements ou de toute autre chose. Il s'agit d'émettre/d'annoncer ces flux ou de souscrire/regarder ces flux ou des transformations de flux qui conduisent à certains événements. Les deux paradigmes de programmation sont donc liés.
Pour moi, c'est comme comparer des oranges à des pommes. Essayons de définir de manière simple ce qui est quoi et ainsi de distinguer les choses:
La programmation réactive est un paradigme de programmation qui est appliqué lorsque l'on veut atteindre une fonctionnalité semblable à la liaison de données dans des bibliothèques comme KnockoutJS. Un autre exemple serait les formules Excel: toutes les cellules sont comme des variables en mémoire. Il y a ceux qui contiennent simplement certaines données et ceux qui sont calculés à partir de ces données. Si le premier change, le second aussi. Faites attention que le paradigme concerne la mise en œuvre à un niveau inférieur; quand quelqu'un parle de programmation réactive, il fait référence aux données, à leurs modifications et à ce qui se passe lorsqu'elles mutent.
D'un autre côté, la programmation événementielle concerne l'architecture du système. Selon ce paradigme, les événements et les gestionnaires d'événements sont à la base d'un système et tout est construit sur eux et autour d'eux. Des exemples courants seraient le multiplexage d'interface utilisateur et de serveur Web. Sentez-vous à quel point tout cela est différent? Le paradigme est appliqué au niveau d'un système entier ou d'un sous-système.
Comment la programmation réactive est-elle liée à Promises? Je pense que les promesses sont une alternative à l'enfer événementiel et de rappel.
Promise est un outil permettant d'atteindre la concurrence et un ordre d'exécution spécifique. Il peut être utilisé dans n'importe quel paradigme.
Dans la pratique, les paradigmes servent différents objectifs et à différents niveaux. Vous pouvez avoir une conception événementielle avec quelques bits de code réactif. Vous pouvez avoir un système distribué qui utilise des modèles de conception réactifs. Cependant, les événements sont finalement un concept de niveau supérieur. Réactif concerne les données et leur réévaluation, une approche pour la mise en œuvre ou ses détails, et les événements sont quelque chose qui découle naturellement d'un cas et guide votre conception.