Tout d'abord, il s'agit d'un cas très spécifique où l'on s'est trompé de méthode dans le but d'intégrer un appel asynchrone dans une base de code très synchrone qui compte plusieurs milliers de lignes et pour laquelle le temps ne permet pas actuellement d'effectuer les changements nécessaires pour "bien faire les choses". Cela fait mal à chaque fibre de mon être, mais la réalité et les idéaux ne s'accordent pas toujours. Je sais que ça craint.
OK, ceci étant dit, comment faire pour que je puisse.. :
function doSomething() {
var data;
function callBack(d) {
data = d;
}
myAsynchronousCall(param1, callBack);
// block here and return data when the callback is finished
return data;
}
Les exemples (ou leur absence) utilisent tous des bibliothèques et/ou des compilateurs, qui ne sont pas viables pour cette solution. J'ai besoin d'un exemple concret de la façon dont on peut le faire bloquer (par exemple, ne PAS laisser la fonction doSomething jusqu'à ce que le callback soit appelé) SANS geler l'interface utilisateur. Si une telle chose est possible en JS.
17 votes
Il n'est tout simplement pas possible de bloquer un navigateur et d'attendre. Ils ne le feront tout simplement pas.
2 votes
Javascript n'a pas de mécanisme de blocage sur la plupart des navigateurs... vous devrez créer un callback qui sera appelé à la fin de l'appel asynchrone pour retourner les données.
0 votes
Je ne pense pas que cela puisse être fait. Javascript (malgré les web workers) est monofilaire - le callback ne peut pas être appelé avant le retour du gestionnaire d'événement actuel. Cela nécessiterait l'équivalent de la fonction async/await de C# en Javascript et je doute qu'une telle bête existe. Je crains que vous ne soyez obligé de réécrire votre code en CPS, aussi ennuyeux que cela puisse être.
9 votes
Vous demandez un moyen de dire au navigateur "Je sais que je viens de te dire d'exécuter cette fonction précédente de manière asynchrone, mais je ne le pensais pas vraiment !". Pourquoi voudriez-vous s'attendre à que cela soit possible ?
3 votes
Merci Dan pour l'édition. Je n'étais pas vraiment impoli, mais ta formulation est meilleure.
0 votes
@lwburk c'est possible en c#, mais les raisons pour lesquelles cela ne s'applique pas en js parce que l'infrastructure n'est pas là en js pour le faire. Je confirmais en gros que ce n'était pas possible.
0 votes
@Inerdial ce n'est pas ennuyeux, c'est plutôt agréable, mais les contraintes de temps pour cet aspect du remaniement ne le permettent pas pour le moment ; cela se fera plus tard dans le cadre d'un remaniement plus important.
0 votes
Duplicata possible : stackoverflow.com/questions/10651755/
2 votes
@RobertC.Barth C'est maintenant possible avec JavaScript aussi. Les fonctions async await n'ont pas encore été ratifiées dans la norme, mais il est prévu qu'elles le soient dans ES2017. Voir ma réponse ci-dessous pour plus de détails.
0 votes
@Wayne
async
est une syntaxe / construction. Il ne s'agit pas nécessairement d'un intention . Cette question fait explicitement la distinction entre les deux.0 votes
@javadba Je ne suis pas sûr de ce que vous essayez de dire, c'est pourquoi je suis assez confiant que la question n'est pas en fait explicitement faire la distinction à laquelle vous faites allusion
0 votes
@Wayne Sur le jvm, on peut lancer un thread séparé qui exécute les tâches de manière asynchrone par rapport au thread principal. Ensuite, sur le thread principal, on a le choix : attendre que ces tâches "asynchrones" se terminent ou continuer son activité. C'est la distinction entre la syntaxe et l'intention. Javascript n'a aucun moyen de convertir la syntaxe
async
syntaxe en un programme non asynchrone comportement . J'ai pu comprendre cette question assez bien à cet égard.0 votes
Deux réponses ci-dessous montrent comment c'est possible aujourd'hui dans le navigateur avec les Service Workers y dans Node.js avec node-fibers . Mais les deux ne sont pas recommandés et doivent être ÉVITÉS.