Je vais tenter le coup, mais je me suis probablement trompé. N'ayant jamais écrit Streams1 (old-streams) ou Streams2, je ne suis probablement pas la personne la mieux placée pour répondre à cette question, mais voilà. Il semble qu'il existe une API Streams1 qui persiste dans une certaine mesure. Dans Streams2, il existe deux modes de streaming qui coule (héritage), et non coulant . En bref, la cale qui soutenait le mode d'écoulement disparaît. C'était le qui a conduit au patch désormais appelé Streams3 ,
Même API que streams2, mais supprime la confusion entre le mode de flux et le mode ancien. mode switch.
- Chaque fois
read()
est appelé et renvoie des données, un événement de données se déclenche.
-
resume()
le fera appeler read() de manière répétée. Sinon, aucun changement.
-
pause()
le fera cesser d'appeler read()
de façon répétée.
-
pipe(dest)
y on('data', fn)
appelle automatiquement resume()
.
- Pas de passage à l'ancien mode. Il n'y a que des flux, et des pauses. Les flux commencent en pause.
Malheureusement, pour comprendre l'une ou l'autre de ces descriptions, qui définissent assez bien Streams3, vous devez d'abord comprendre Streams1 et les anciens flux.
Backstory
Tout d'abord, regardons ce que la documentation de Node v0.10.25 dit sur les deux modes,
Les flux lisibles ont deux "modes" : un mode flottant et un mode non flottant. En mode fluide, les données sont lues depuis le système sous-jacent et fournies à votre programme aussi rapidement que possible. En mode non-fluidant, vous devez appeler explicitement stream.read() pour obtenir des morceaux de données. - Docs sur Node v0.10.25
Isaac Z. Schlueter a dit dans des diapositives de novembre que j'ai déterrées :
streams2
- "sucer des ruisseaux"
- Au lieu de cracher des événements 'data', appelez read() pour extraire les données de la source.
- Résout tous les problèmes (à notre connaissance)
Donc il semble que dans streams1, vous créez un objet et appelez .on('data', cb)
à cet objet. Cela permettait de déclencher l'événement, et vous étiez alors à la merci du flux. Dans Streams2, les flux internes ont des tampons et vous demandez des données à ces flux explicitement (en utilisant `.read). Isaac précise ensuite comment la compatibilité descendante fonctionne dans Streams2 pour que les modules Streams1 (old-stream) continuent à fonctionner.
shim streams1 old-mode
- Les nouveaux flux peuvent passer en mode ancien, où ils crachent des "données".
- Si vous ajoutez un gestionnaire d'événement 'data', ou si vous appelez pause() ou resume(), alors le commutateur de l'événement 'data' est activé.
- Apporter des modifications minimales aux tests existants pour que nous restions honnêtes.
Ainsi, dans Streams2, un appel à .pause()
o .resume()
déclenche la cale. Et, ça devrait, non ? Dans Streams2, vous avez le contrôle sur le moment où la .read()
et tu n'attrapes pas les trucs qui te sont lancés. Cela a déclenché un mode hérité qui a agi indépendamment de Streams2.
Prenons un exemple de la diapositive d'Isaac,
createServer(function(q,s) {
// ADVISORY only!
q.pause()
session(q, function(ses) {
q.on('data', handler)
q.resume()
})
})
- Dans Streams1,
q
commence tout de suite à lire et à émettre (en perdant probablement des données), jusqu'à ce que l'appel à q.pause
conseille q
pour arrêter d'aspirer des données mais pas d'émettre des événements pour effacer ce qu'il a déjà lu.
- Dans Streams2,
q
est en pause jusqu'à ce que l'appel à .pause()
ce qui signifie émuler l'ancien mode.
- Dans Streams3,
q
démarre en tant que pausé, n'ayant jamais lu depuis la poignée du fichier, ce qui fait que les q.pause()
un noop, et sur l'appel à q.on('data', cb)
appellera q.resume
jusqu'à ce qu'il n'y ait plus de données dans le tampon. Et, ensuite, appelez à nouveau q.resume
qui font la même chose.
0 votes
Article brillant sur les flux1,2 et 3 : medium.com/the-node-js-collection/