À l'aide de async/await avec une boucle forEach

Existe-il des problèmes avec l'utilisation de async/await dans un forEach boucle? Je suis en train de parcourir un tableau de fichiers et await sur le contenu de chaque fichier. 

import fs from 'fs-promise'

async function printFiles () {
  const files = await getFilePaths() //Assume this works fine

  files.forEach(async (file) => {
    const contents = await fs.readFile(file, 'utf8')
    console.log(contents)
  })
}

printFiles()

Ce code fonctionne, mais quelque chose pourrait aller mal avec cela? J'ai eu quelqu'un me dire que vous n'êtes pas censé utiliser async/await dans un ordre supérieur de la fonction comme cela, alors je voulais juste vous demander si il n'y avait aucun problème avec cela.

InformationsquelleAutor saadq | 2016-06-01
  1. 1407

    Vous assurer que le code fonctionne, mais je suis sûr qu'on ne fait pas ce que vous attendez pour le faire. Il a juste déclenche de multiples appels asynchrones, mais le printFiles fonction ne revenez immédiatement après.

    Si vous souhaitez lire les fichiers en séquence, vous ne pouvez pas utiliser forEach en effet. Il suffit d'utiliser un moderne for … of boucle au lieu de cela, en ce qui await fonctionne comme prévu:

    async function printFiles () {
  const files = await getFilePaths();

  for (const file of files) {
    const contents = await fs.readFile(file, 'utf8');
    console.log(contents);
  }
}

    Si vous souhaitez lire les fichiers en parallèle, vous ne pouvez pas utiliser forEach en effet. Chacun des async rappel des appels de fonction retourne une promesse, mais vous êtes les jeter à la poubelle au lieu de les attendent. Utilisez simplement map au lieu de cela, et vous pouvez attendre la matrice de promesses que vous aurez avec Promise.all:

    async function printFiles () {
  const files = await getFilePaths();

  await Promise.all(files.map(async (file) => {
    const contents = await fs.readFile(file, 'utf8')
    console.log(contents)
  }));
}
    • Pourriez-vous expliquer pourquoi for ... of ... travail?
    • ok, je sais pas pourquoi... à l'Aide de Babel va transformer async/await de générateur de fonction et l'utilisation de forEach signifie que chaque itération dispose d'un générateur de fonction, qui n'a rien à voir avec les autres. donc, ils vont être exécutés de manière indépendante et n'a pas de contexte de next() avec les autres. En fait, un simple for() boucle fonctionne aussi parce que les itérations sont également en un seul générateur de fonction.
    • En bref, parce qu'il a été conçu pour fonctionner 🙂 await suspend l'actuel function de l'évaluation, y compris toutes les structures de contrôle. Oui, il est tout à fait semblables à des générateurs à cet égard (c'est pourquoi elles sont utilisées pour polyfill async/await).
    • Excellent exemple. Je vous remercie. J'ai utilisé la Matrice.de la recherche et de remplacement d'un dom nodelist HTML (lignes de la table). La carte a besoin d'une matrice de type collection. Pour le tableau, comme des objets, comme la Dom Nodelist vous pouvez utiliser le Tableau.partir de.
    • Donc files.map(async (file) => ... est équivalent à files.map((file) => new Promise((rej, res) => { ...?
    • Pas vraiment, un async fonction est tout à fait différent d'un Promise exécuteur de rappel, mais oui, les map de rappel renvoie une promesse dans les deux cas.
    • Quand vous venez d'apprendre à propos de JS promesses, mais au lieu d'utiliser une demi-heure de la traduction latine. J'espère que vous êtes fiers @Bergi 😉
    • Ainsi en ce qui concerne await dans quel camp ne for( in ) résident? les pouces vers le bas avec forEach ou pouces avec for of ??
    • C'est un syntaxiques de la boucle et de travailler avec des await, mais vous avez rarement besoin d'énumérer les propriétés de l'objet.
    • J'ai aussi eu ce doute, j'ai trouvé ce lien que j'ai trouvé utile Iteration_protocols
    • stackoverflow.com/questions/48349699/...
    • Cette réponse est le meilleur: await Promise.all(_.map(arr, async (val) => {...}); résolu mon problème. Bien sûr, chaque async callback retourne une promesse que je n'étais pas en attente sur.
    • Pour ceux qui ne connaissent pas, Promesse.tous les renvoie une promesse unique qui résout lorsque toutes les promesses dans le tableau sont résolus. (en gros, attend toutes les promesses pour conclure)
    • Je pense que le deuxième paragraphe devrait être: "Si vous voulez lire les fichiers en parallèle, vous ne pouvez pas utiliser for..of" ? Parce que vous pouvez lire les fichiers en parallèle avec la forEach, c'est juste qu'il sera très laid parce que vous ne pouvez pas await il.
    • Si vous n'avez pas l'intention d'attendre d'eux, puis for…of qui fonctionne aussi pour forEach. Non, je veux vraiment dire que le paragraphe pour souligner qu'il n'y a pas de place pour .forEach moderne du code JS.
    • N'est-ce pas mauvais pour la performance ? Si vous avez besoin d'effectuer 3 demandes, vous ne pouvez pas faire toutes en même temps, donc si chacun prend une seconde, votre programme va prendre 3 secondes pour s'exécuter. Mais si vous utilisez map ou forEach, les requêtes s'exécutent en parallèle.
    • Je ne comprends pas. Ce qui est mauvais pour les performances par rapport à quoi?
    • for..of est mauvais pour la performance en comparaison à forEach/map, parce que for..of arrêt à chaque itération, donc, si je fais 3 sur demande, chaque demande devra attendre pour les précédentes requêtes. Mais avec forEach/map, toutes les demandes seront faites en parallèle.
    • Pas de. queries.forEach(q => asyncRequest(q)); fait exactement la même chose que for (const q of queries) asyncRequest(q);. Il n'y a aucune différence dans les performances, et les deux vont exécuter les requêtes en parallèle. Bien sûr, dans les deux vous pouvez attendre pour rien - pour savoir comment procéder, voir ma réponse.
    • Je parle de ceci: gist.github.com/doubleOrt/598659adfefdd941f2a98512f0f7f078
    • Oui, c'est fondamentalement les deux approches de ma réponse. Aucun d'eux utilise forEach. Où est le problème?
    • J'aurais pu utiliser forEach (fonctionne de la même comme map concernant le temps d'exécution). Mais comme vous pouvez le voir dans mon précédent commentaire, je parlais soit forEach ou map contre for..of. J'ai dit: pour..de l'est mauvais pour la performance en comparaison à forEach/map.
    • Cependant, comment est-ce vrai (votre réponse): Si vous souhaitez lire les fichiers en parallèle, vous ne pouvez pas utiliser forEach en effet. je pense que vous pouvez le faire, même chose que votre map exemple, sauf avec forEach il sera moche et impropre à une async/await.
    • Mais c'est faux: for…of n'est pas mauvais pour la performance en comparaison à forEach si elle est utilisée de la même façon impropre, sans attendre quoi que ce soit. Et oui, "ne peut pas être utilisé" signifie "est impropre".
    • Êtes-vous ce qui suggère un cas où vous n'avez pas await quelle que soit la demande que vous faites à l'intérieur d'un for..of ? Si oui, ok, mais vous n'acceptez que votre deuxième exemple est beaucoup plus performant que votre premier exemple ?
    • Oui, c'est ce que j'ai écrit dans mon commentaire ci-dessus. Bien sûr, il ne ferait aucun sens et est inapte à résoudre les OPs problème, peu importe que ce soit avec forEach ou for…of. Et non, je ne voudrais pas comparer les deux (for…of+await vs Promise.all+map) en termes de "performance" à tous - ils sont juste différents, dans de nombreux autres plus importantes ce qui concerne. Le choix séquentiel vs parallèle de l'exécution est une décision qui implique de nombreux autres facteurs, et bien sûr en parallèle généralement termine plus vite.
    • Bien sûr il y a des cas où la for..of peut-être la seule façon d'aller de l'e.g si chaque demande a une dépendance sur la demande précédente), mais un débutant pourrait opter pour la for..of solution parce que c'est plus simple.
    • Cependant, je ne comprends toujours pas comment cela est correct: Si vous souhaitez lire les fichiers en parallèle, vous ne pouvez pas utiliser forEach en effet.
    • Vous ne pouvez pas l'utiliser parce que vous ne pouvez pas attendre le résultat. Bien sûr, si vous avez utilisé - comme l'OP n'ont - elles se déroulent en parallèle, mais forEach est absolument inapte comme vous l'avez dit vous-même.
    • Oh, maintenant je comprends ce que tu veux dire par cette partie. Mais c'est vraiment vague, parce que, techniquement, vous pouvez l'utiliser, mais cela ne signifie pas que vous devriez. Votre réponse fondamentalement véhicule qu'il n'est pas possible d'exécuter des requêtes en parallèle à l'aide de forEach.
    • J'ai pensé "et attendez la fin de la" implicite. Mais encore, si "impossible" exprime la même chose que "devrait absolument pas" je vais bien. Garder les choses simples pour les débutants: ils doivent jamais utiliser forEach, c'est tout ce qu'ils doivent savoir.
    • Un autre "ne pourriez-vous pas...", ne pourrait-on pas utiliser un .joindre avec ce que bien d'attendre que toutes les promesses pour être complet? Ensuite, vous pouvez parcourir les fichiers dans la liste, etc. J'aime vraiment @Babak de la Tâche et traversable liste. Je vais trouver une excuse à utiliser que quelque part, dès que je peux.
    • est une méthode sur les tableaux de chaînes de caractères, il n'attend pas les promesses. Ce que vous pouvez faire est de var string = (await Promise.all(…)).join(…).
    • href="https://stackoverflow.com/a/49573609/1048572">const déclarations fonctionnent parfaitement bien dans les boucles. Les variables est jamais réattribué.
    • Solution qui fonctionne pour moi. Cependant, je ne comprends toujours pas pourquoi foreach avec async ne fonctionne pas. Depuis, nous avons spécifié await à l'intérieur de la boucle, il doit attendre la réponse?
    • Seul le async function appel attend et retourne une promesse. forEach ne se soucient pas de cette promesse.
    • peut-être, puisque c'est un canoniques dupe cible, vous pouvez ajouter une alternative qui évite async / await syntaxe et retourne juste la promesse d' map() directement? Je comprends que le moment de console.log() n'allait plus être la même, mais il semble être la confusion sur le fait que async n'est-ce pas en quelque sorte nécessaires à l'utilisation de Promise.all() et map().
    • ou vous pourriez avoir la gentillesse de proposer des dupe des cibles qui ne font pas les choses moches comme var promises = []; array.forEach(value => { promises.push(someAsync(value)); }); return Promise.all(promises); parce que je vois beaucoup de personnes, ou des questions similaires avec de meilleures réponses, mais le code est trop compliqué pour être réutilisables comme un double de la cible.
    • Je suis en gardant une liste de ceux-là même, pour quand, un jour, je vais écrire un nouveau canonique question avec des réponses détaillées...
    • Merci, c'est court et simple!

    InformationsquelleAutor Bergi
  2. 111

    Avec ES2018, vous êtes en mesure de simplifier grandement toutes les réponses ci-dessus à:

    async function printFiles () {
  const files = await getFilePaths()

  for await (const file of fs.readFile(file, 'utf8')) {
    console.log(contents)
  }
}

    Voir spec: https://github.com/tc39/proposal-async-iteration

    2018-09-10: Cette réponse a été l'objet de beaucoup d'attention récemment, voir Axel Rauschmayer du blog pour plus d'informations sur asynchrones itération: http://2ality.com/2016/10/asynchronous-iteration.html

    • Upvoted, ce serait génial si vous pouviez mettre un lien vers le spec dans votre réponse pour tous ceux qui veulent en savoir plus sur async itération.
    • Où est file définis dans votre code?
    • Ne pas savoir d'où file est défini. C'est porté de 1:1 à partir de la question ci-dessus.
    • Quelle est la performance de cela?
    • Ne devrait-elle pas être contenu au lieu de fichier dans l'itérateur
    • Pourquoi les gens sont upvoting cette réponse? Regardez de plus près à la réponse, question, et la proposition. Après la of devrait être l'asynchrone en fonction retournera un tableau. Il ne fonctionne pas et a dit Francisco;
    • Je ne pense pas que cette réponse l'adresse de la question initiale. for-await-of avec un synchrones itérable (un tableau dans notre cas) ne couvre pas le cas de l'itération simultanément un tableau à l'aide des opérations asynchrones à chaque itération. Si je ne me trompe pas, à l'aide de for-await-of avec un synchrones itératif sur les non-promesse de des valeurs est le même qu'en utilisant un simple for-of.
    • Totalement d'accord avec @AntonioVal. Ce n'est pas une réponse.
    • La façon dont nous les délégués files tableau à la fs.readFile ici? Il y de itératif?
    • Alors que je suis d'accord ce n'est pas une réponse, upvoting une proposition est un moyen d'augmenter sa popularité qui pourrait le rendre disponibles plus tôt pour l'utiliser plus tard.

    InformationsquelleAutor Francisco Mateo
  3. 34

    Au lieu de Promise.all en conjonction avec Array.prototype.map (ce qui ne garantit pas l'ordre dans lequel les Promises sont résolu), j'utilise Array.prototype.reduce, en commençant avec une résolu Promise:

    async function printFiles () {
  const files = await getFilePaths();

  await files.reduce(async (promise, file) => {
    //This line will wait for the last async function to finish.
    //The first iteration uses an already resolved Promise
    //so, it will immediately continue.
    await promise;
    const contents = await fs.readFile(file, 'utf8');
    console.log(contents);
  }, Promise.resolve());
}
    • Cela fonctionne parfaitement, merci beaucoup. Pourriez-vous expliquer ce qui se passe ici avec Promise.resolve() et await promise;?
    • C'est assez sympa. Suis-je en droit de penser que les fichiers seront lus dans l'ordre et pas tous à la fois?
    • retourne un déjà résolu Promise objet, de sorte que reduce a un Promise pour commencer. await promise; va attendre le dernier Promise dans la chaîne afin de les résoudre. @GollyJer Les fichiers seront traitées de manière séquentielle, un à la fois.
    • Très cool l'utilisation de réduire, merci pour le commentaire! Je vais juste dire que, contrairement à certaines autres méthodes mentionnées dans les commentaires, celui-ci est synchrone, ce qui signifie que les fichiers sont lus l'un après l'autre et non pas en parallèle (puisque la prochaine itération de la fonction de réduction s'appuie sur l'itération précédente, il doit être synchrone).
    • Tu veux dire séquentiel, pas synchrone. C'est encore asynchrone si d'autres choses sont prévues, elles s'exécutent dans entre les itérations ici.
    InformationsquelleAutor Timothy Zorn
  4. 25

    La p-itération module npm met en œuvre la Matrice d'itération méthodes afin qu'ils puissent être utilisés d'une manière très simple avec async/await.

    Un exemple avec votre cas:

    const { forEach } = require('p-iteration');
const fs = require('fs-promise');

(async function printFiles () {
  const files = await getFilePaths();

  await forEach(files, async (file) => {
    const contents = await fs.readFile(file, 'utf8');
    console.log(contents);
  });
})();
    • J'aime ce que il a les mêmes fonctions / méthodes JS lui-même - dans mon cas, j'avais besoin de some plutôt que forEach. Merci!
    InformationsquelleAutor Antonio Val
  5. 15

    Voici quelques forEachAsync prototypes. Remarque: vous aurez besoin de await eux:

    Array.prototype.forEachAsync = async function (fn) {
    for (let t of this) { await fn(t) }
}

Array.prototype.forEachAsyncParallel = async function (fn) {
    await Promise.all(this.map(fn));
}

    Note alors que vous pouvez inclure dans votre propre code, vous ne devez pas inclure cela dans les bibliothèques que vous les distribuer aux autres (pour éviter de polluer leur globals).

    • Bien que je serais hésitez pas à ajouter des choses directement sur le prototype, c'est une belle async forEach mise en œuvre
    • Tant que le nom est unique dans l'avenir (comme je l'avais utiliser _forEachAsync) ce qui est raisonnable. Je pense aussi que c'est la plus belle réponse qu'il permet d'économiser beaucoup de code réutilisable.
    • Ils doivent être autonomes fonctions. Nous avons des modules pour ne pas polluer globals avec nos affaires personnelles.
    • C'est pour éviter de polluer les autres gens du code. Si le code appartient à notre organisation personnelle, et les variables globales sont dans un fichier identifié (globals.js serait bien), on peut ajouter des variables globales comme on les aime.
    • C'est pour éviter généralement reconnus des mauvaises pratiques. C'est vrai, cela peut être fait, aussi longtemps que vous utilisez seulement la première partie du code, ce qui arrive rarement. Le problème est que lorsque vous utilisez une tierce partie libs, il peut y avoir quelques autres gars qui se sent de la même façon et modifie le même globals, juste parce que ça me semblait une bonne idée au moment de la lib a été écrit.
    • Les pratiques sont considérées comme des mauvaises en raison pour les raisons indiquées dans le commentaire que vous répondez. Une troisième partie qui a lu mon commentaire ne serait pas inclure prototype extras dans le code de la bibliothèque de leur distribuer à d'autres.
    • C'est correct. Il y a beaucoup de code hérité autour de qui fait déjà cela et peut potentiellement incompatible avec votre propre globals, je vois prototype de la pollution " avertissement avec npm audit ici et là. Mon point était de ne pas recommander l'approche énumérées dans la réponse à une personne qui n'est pas pleinement conscients des conséquences, en particulier en 2018.
    • Assurez-vous. J'ai ajouté un avertissement à la question, pour économiser de l' (pas particulièrement productif) discussion ici.

    InformationsquelleAutor Matt
  6. 2

    Les deux solutions ci-dessus ne fonctionne, cependant, Antonio fait le travail avec moins de code, voici comment il m'a aidé à résoudre des données de ma base de données, à partir de plusieurs différent de l'enfant refs et puis en poussant tous dans un tableau et de le résoudre en une promesse, après tout, est fait:

    Promise.all(PacksList.map((pack)=>{
    return fireBaseRef.child(pack.folderPath).once('value',(snap)=>{
        snap.forEach( childSnap => {
            const file = childSnap.val()
            file.id = childSnap.key;
            allItems.push( file )
        })
    })
})).then(()=>store.dispatch( actions.allMockupItems(allItems)))
    InformationsquelleAutor Hooman Askari
  7. 2

    c'est assez indolore de la pop un couple de méthodes dans un fichier qui va gérer les données asynchrone dans un sérialisée de l'ordre et de donner une plus classique de la saveur à votre code. Par exemple:

    module.exports = function () {
  var self = this;

  this.each = async (items, fn) => {
    if (items && items.length) {
      await Promise.all(
        items.map(async (item) => {
          await fn(item);
        }));
    }
  };

  this.reduce = async (items, fn, initialValue) => {
    await self.each(
      items, async (item) => {
        initialValue = await fn(initialValue, item);
      });
    return initialValue;
  };
};

    maintenant, en supposant que c'est enregistré à". /myAsync.js " vous pouvez faire quelque chose de similaire à ci-dessous à côté d'un fichier:

    ...
/* your server setup here */
...
var MyAsync = require('./myAsync');
var Cat = require('./models/Cat');
var Doje = require('./models/Doje');
var example = async () => {
  var myAsync = new MyAsync();
  var doje = await Doje.findOne({ name: 'Doje', noises: [] }).save();
  var cleanParams = [];

  //FOR EACH EXAMPLE
  await myAsync.each(['bork', 'concern', 'heck'], 
    async (elem) => {
      if (elem !== 'heck') {
        await doje.update({ $push: { 'noises': elem }});
      }
    });

  var cat = await Cat.findOne({ name: 'Nyan' });

  //REDUCE EXAMPLE
  var friendsOfNyanCat = await myAsync.reduce(cat.friends,
    async (catArray, friendId) => {
      var friend = await Friend.findById(friendId);
      if (friend.name !== 'Long cat') {
        catArray.push(friend.name);
      }
    }, []);
  //Assuming Long Cat was a friend of Nyan Cat...
  assert(friendsOfNyanCat.length === (cat.friends.length - 1));
}
    • Mineur additif, n'oubliez pas d'inclure vos attendent/asyncs dans les blocs try/catch!!
    InformationsquelleAutor Jay Edwards
  8. 1

    Un important mise en garde est: La await + for .. of méthode et la forEach + async façon en fait avoir un effet différent.

    Avoir await l'intérieur d'un vrai for boucle assurez-vous que tous les appels asynchrones sont exécutées une par une. Et le forEach + async façon se déclenche toutes les promesses dans le même temps, ce qui est plus rapide mais parfois débordé(si vous faites quelques DB de requête ou visiter quelques-uns des services web avec les restrictions de volume et ne veulent pas de feu de 100 000 appels à un moment).

    Vous pouvez également utiliser reduce + promise(moins élégant) si vous n'utilisez pas async/await et veulent s'assurer que les fichiers sont en lecture l'un après l'autre. 

    files.reduce((lastPromise, file) => 
 lastPromise.then(() => 
   fs.readFile(file, 'utf8')
 ), Promise.resolve()
)

    Ou vous pouvez créer un forEachAsync pour les aider, mais, fondamentalement, utiliser le même pour la boucle sous-jacent.

    Array.prototype.forEachAsync = async function(cb){
    for(let x of this){
        await cb(x);
    }
}
    InformationsquelleAutor Leon li
  9. 1

    À l'aide de la Tâche, futurize, et un traversable Liste, vous pouvez simplement faire

    async function printFiles() {
  const files = await getFiles();

  List(files).traverse( Task.of, f => readFile( f, 'utf-8'))
    .fork( console.error, console.log)
}

    Ici est de savoir comment vous définissez ce

    import fs from 'fs';
import { futurize } from 'futurize';
import Task from 'data.task';
import { List } from 'immutable-ext';

const future = futurizeP(Task)
const readFile = future(fs.readFile)

    Un autre moyen d'avoir structuré le code désiré serait

    const printFiles = files => 
  List(files).traverse( Task.of, fn => readFile( fn, 'utf-8'))
    .fork( console.error, console.log)

    Ou peut-être même plus fonctionnellement orientée

    //90% of encodings are utf-8, making that use case super easy is prudent

//handy-library.js
export const readFile = f =>
  future(fs.readFile)( f, 'utf-8' )

export const arrayToTaskList = list => taskFn => 
  List(files).traverse( Task.of, taskFn ) 

export const readFiles = files =>
  arrayToTaskList( files, readFile )

export const printFiles = files => 
  readFiles(files).fork( console.error, console.log)

    Puis à partir de la fonction parent

    async function main() {
  /* awesome code with side-effects before */
  printFiles( await getFiles() );
  /* awesome code with side-effects after */
}

    Si vous voulais vraiment plus de souplesse dans l'encodage, vous pouvez simplement le faire (pour le fun, je suis en utilisant le projet de Pipe Avant opérateur )

    import { curry, flip } from 'ramda'

export const readFile = fs.readFile 
  |> future,
  |> curry,
  |> flip

export const readFileUtf8 = readFile('utf-8')

    PS - je n'ai pas essayé ce code sur la console, pourrait avoir des fautes de frappe... "straight freestyle, hors de la partie supérieure de la coupole!" que les années 90, des enfants me le dire. :-p

    InformationsquelleAutor Babakness
  10. 1

    En plus de @Bergi réponse, je tiens à offrir une troisième alternative. Il est très similaire à @Bergi 2e exemple, mais au lieu de l'attente de chaque readFile individuellement, vous créez un tableau de promesses, chaque qui vous attendent à la fin.

    import fs from 'fs-promise';
async function printFiles () {
  const files = await getFilePaths();

  const promises = files.map((file) => fs.readFile(file, 'utf8'))

  const contents = await Promise.all(promises)

  contents.forEach(console.log);
}

    Noter que la fonction transmise à .map() n'a pas besoin d'être async, depuis fs.readFile retourne une Promesse d'objets de toute façon. Donc promises est un tableau de la Promesse d'objets, qui peuvent être envoyés à Promise.all().

    Dans @Bergi réponse, la console peut enregistrer le contenu du fichier de commande. Par exemple, si un très petit fichier terminé la lecture devant un très gros fichier, il sera enregistré en premier, même si le fichier de petite taille, vient après le fichier de grande taille dans le files tableau. Cependant, dans ma méthode ci-dessus, vous avez la garantie de la console enregistre les fichiers dans le même ordre qu'ils sont lus.

    InformationsquelleAutor chharvey
  11. 1

    Actuellement le Tableau.forEach propriété prototype ne prend pas en charge des opérations asynchrones, mais nous pouvons créer notre propre poly-remplir pour répondre à nos besoins.

    //Example of asyncForEach Array poly-fill for NodeJs
//file: asyncForEach.js
//Define asynForEach function 
async function asyncForEach(iteratorFunction){
  let indexer = 0
  for(let data of this){
    await iteratorFunction(data, indexer)
    indexer++
  }
}
//Append it as an Array prototype property
Array.prototype.asyncForEach = asyncForEach
module.exports = {Array}

    Et c'est tout! Vous avez maintenant un async forEach méthode disponible sur tous les tableaux qui sont définies à l'issue de ces opérations.

    Nous allons tester...

    //Nodejs style
//file: someOtherFile.js

const readline = require('readline')
Array = require('./asyncForEach').Array
const log = console.log

//Create a stream interface
function createReader(options={prompt: '>'}){
  return readline.createInterface({
    input: process.stdin
    ,output: process.stdout
    ,prompt: options.prompt !== undefined ? options.prompt : '>'
  })
}
//Create a cli stream reader
async function getUserIn(question, options={prompt:'>'}){
  log(question)
  let reader = createReader(options)
  return new Promise((res)=>{
    reader.on('line', (answer)=>{
      process.stdout.cursorTo(0, 0)
      process.stdout.clearScreenDown()
      reader.close()
      res(answer)
    })
  })
}

let questions = [
  `What's your name`
  ,`What's your favorite programming language`
  ,`What's your favorite async function`
]
let responses = {}

async function getResponses(){
//Notice we have to prepend await before calling the async Array function
//in order for it to function as expected
  await questions.asyncForEach(async function(question, index){
    let answer = await getUserIn(question)
    responses[question] = answer
  })
}

async function main(){
  await getResponses()
  log(responses)
}
main()
//Should prompt user for an answer to each question and then 
//log each question and answer as an object to the terminal

    Nous pourrions faire de même pour certaines autres fonctions de tableau comme carte...

    async function asyncMap(iteratorFunction){
  let newMap = []
  let indexer = 0
  for(let data of this){
    newMap[indexer] = await iteratorFunction(data, indexer, this)
    indexer++
  }
  return newMap
}

Array.prototype.asyncMap = asyncMap

    ... et ainsi de suite 🙂

    Des choses à noter:

    • Votre iteratorFunction doit être une fonction async ou promesse
    • Les tableaux créés avant Array.prototype.<yourAsyncFunc> = <yourAsyncFunc> ne disposent pas de cette fonctionnalité disponible
    InformationsquelleAutor Beau
  12. 0

    Similaire à Antonio Val p-itération, une alternative mnp module est async-af:

    const AsyncAF = require('async-af');
const fs = require('fs-promise');

function printFiles() {
  //since AsyncAF accepts promises or non-promises, there's no need to await here
  const files = getFilePaths();

  AsyncAF(files).forEach(async file => {
    const contents = await fs.readFile(file, 'utf8');
    console.log(contents);
  });
}

printFiles();

    Sinon, async-af possède une méthode statique (log/logAF) qui enregistre les résultats de promesses:

    const AsyncAF = require('async-af');
const fs = require('fs-promise');

function printFiles() {
  const files = getFilePaths();

  AsyncAF(files).forEach(file => {
    AsyncAF.log(fs.readFile(file, 'utf8'));
  });
}

printFiles();

    Cependant, le principal avantage de la bibliothèque, c'est que vous pouvez enchaîner les méthodes asynchrones pour faire quelque chose comme:

    const aaf = require('async-af');
const fs = require('fs-promise');

const printFiles = () => aaf(getFilePaths())
  .map(file => fs.readFile(file, 'utf8'))
  .forEach(file => aaf.log(file));

printFiles();

    async-af

    InformationsquelleAutor Scott Rudiger
  13. 0

    Bergi de la solution fonctionne très bien quand fs est la promesse base.
    Vous pouvez utiliser bluebird, fs-extra ou fs-promise pour cela.

    Cependant, la solution pour nœud natif fs bibliothèque est comme suit:

    const result = await Promise.all(filePaths
    .map( async filePath => {
      const fileContents = await getAssetFromCache(filePath, async function() {

        //1. Wrap with Promise    
        //2. Return the result of the Promise
        return await new Promise((res, rej) => {
          fs.readFile(filePath, 'utf8', function(err, data) {
            if (data) {
              res(data);
            }
          });
        });
      });

      return fileContents;
    }));

    Remarque:
    require('fs') obligatoirement prend fonction en tant que 3e arguments, sinon déclenche une erreur:

    TypeError [ERR_INVALID_CALLBACK]: Callback must be a function
    InformationsquelleAutor myDoggyWritesCode
  14. -3

    Je voudrais utiliser le bien testé (en millions de téléchargements par semaine) pify et async modules. Si vous n'êtes pas familier avec la async module, je vous recommande fortement de vérifier ses docs. J'ai vu plusieurs devs perdre du temps à recréer ses méthodes, ou pire, de décisions difficiles à maintenir async code lors d'ordre supérieur de méthodes asynchrones serait de simplifier le code.

    const async = require('async')
const fs = require('fs-promise')
const pify = require('pify')

async function getFilePaths() {
    return Promise.resolve([
        './package.json',
        './package-lock.json',
    ]);
}

async function printFiles () {
  const files = await getFilePaths()

  await pify(async.eachSeries)(files, async (file) => {  //<-- run in series
  //await pify(async.each)(files, async (file) => {  //<-- run in parallel
    const contents = await fs.readFile(file, 'utf8')
    console.log(contents)
  })
  console.log('HAMBONE')
}

printFiles().then(() => {
    console.log('HAMBUNNY')
})
//ORDER OF LOGS:
//package.json contents
//package-lock.json contents
//HAMBONE
//HAMBUNNY
```
    • C'est un pas dans la mauvaise direction. Voici une carte que j'ai créé pour aider les gens coincés dans le rappel de l'enfer dans le moderne JS ère: github.com/jmjpro/async-package-to-async-await/blob/master/....
    • comme vous pouvez voir ici, je suis intéressé et ouvert à l'aide de async/await au lieu de l'asynchrone lib. Maintenant, je pense que chacun a un lieu et une heure. Je ne suis pas convaincu que l'async lib == "rappel de l'enfer" et async/await == "moderne JS ère". omi, quand async lib > async/await: 1. complexe de flux (par exemple, la file d'attente, le fret, même auto quand les choses deviennent compliquées) 2. la simultanéité 3. soutenir les tableaux/objets/iterables 4. err manutention
    InformationsquelleAutor Zachary Ryan Smith