Cette fois, je vais vous présenter la méthode de publication d'événement JS d'abord puis de souscription. Quelles sont les précautions pour réaliser d'abord la publication d'événement JS puis de souscription. Voici les. cas pratiques. Jetons un coup d'oeil.
J'ai déjà écrit un gestionnaire d'événements , qui est un modèle normal d'abonnement puis de publication. Mais dans les scénarios réels, nous devons garantir que ceux qui s’abonnent plus tard puissent également recevoir les messages publiés. Par exemple, si nous suivons le compte public WeChat, nous pouvons toujours voir des actualités historiques. Semblables aux messages hors ligne QQ, je vous les enverrai d'abord et vous pourrez les recevoir après vous être connecté. Il s'agit de garantir que toutes les méthodes qui s'abonnent à l'événement peuvent être exécutées.
var eventManger = { cached: {}, handlers: {}, //类型,绑定事件 addHandler: function (type, handler) { if (typeof handler !== "function") return; if (typeof this.handlers[type] == "undefined") { this.handlers[type] = []; } this.handlers[type].push(handler); if (this.cached[type] instanceof Array) { //说明有缓存的 可以执行 handler.apply(null, this.cached[type]); } }, removeHandler: function (type, handler) { var events = this.handlers[type]; for (var i = 0, len = events.length; i < len; i++) { if (events[i] == handler) { events.splice(i, 1); break; } } }, trigger: function (type) { //如果有订阅的事件,这个时候就触发了 if (this.handlers[type] instanceof Array) { var handlers = this.handlers[type]; var args = Array.prototype.slice.call(arguments, 1); for (var i = 0, len = handlers.length; i < len; i++) { handlers[i].apply(null, args); } } //默认缓存 this.cached[type] = Array.prototype.slice.call(arguments, 1); } };
En fait, cela ajoute juste quelques lignes de code. Mettez en cache les paramètres du dernier déclencheur. Ensuite, faites un jugement lors de l'ajout d'un handle. S'il y a déjà des paramètres en cache lors de l'abonnement, cela signifie que la méthode peut être exécutée.
eventManger.addHandler("test", function (res) { console.log("先订阅,后发布1", res); }) eventManger.trigger("test", 2); eventManger.addHandler("test", function (res) { console.log("先发布,后订阅2", res); }) eventManger.addHandler("test", function (res) { console.log("先发布,后订阅3", res); })
Mon scénario actuel est que la méthode B ne peut être exécutée qu'après le déclenchement de l'événement A. Mais la méthode B doit être complétée après la méthode C. Autrement dit, B dépend de l’achèvement de A et C. Et A sera déclenché rapidement presque à chaque fois. Bien sûr, vous pouvez configurer deux commutateurs variables et une fonction proxy, puis exécuter B une fois les deux événements terminés. Le code est le suivant :
var aReady = false;var cReady = false; eventManger.addHandler("A", function () { aReady = true; console.log("do A"); proxyC(); }); eventManger.trigger("A", 2);function doB() { console.log("do B"); //实际B中的方法需要在A事件成功之后才能执行}function doC() { console.log("do C"); cReady = true; proxyC(); }function proxyC() { aReady && cReady && doB(); } doC();
Cette fonction est implémentée, mais la lisibilité est mauvaise, et la souscription à l'événement doit être dans la bonne position Si c'est avant le déclencheur, doB ne sera jamais exécuté, et il y a deux autres codes et une méthode, le plus stupide est d'utiliser une variable plus setTimeout pour déterminer le statut, ce qui peut conduire à une boucle infinie.
var aReady = false; eventManger.addHandler("A", function () { aReady = true; console.log("do A"); });function doB() { console.log("do B"); //实际B中的方法需要在A事件成功之后才能执行}function doC() { console.log("do C"); if (!aReady) { console.log("wating..."); setTimeout(doC, 50); return; } doB(); } doC(); eventManger.trigger("A", 2);//模拟A事件触发迟
Cette méthode est probablement la plus indésirable. Étant donné que des événements externes peuvent provoquer un échec, il n’y a aucune issue ici. C'est comme creuser un trou. Mais si l'événement prend en charge la publication d'abord puis l'abonnement, le problème est simple :
eventManger.trigger("A", 2);function doB() { console.log("do B"); //实际B中的方法需要在A事件成功之后才能执行}function doC() { console.log("do c"); eventManger.addHandler("A", function () { console.log("do a"); doB(); }); } doC();
Cela rend les choses beaucoup plus claires. Les abonnements aux événements n'ont pas à se soucier autant de l'emplacement de l'appel. Ce qui précède mémorise simplement les paramètres d'appel les plus récents, qui peuvent être utilisés pour déclencher les événements souscrits ultérieurs. Ceci convient aux événements ponctuels (événements qui ne seront déclenchés qu'une seule fois par cycle). S'il s'agit d'un événement tel qu'un message push, il sera déclenché en continu. Si vous voulez vous assurer que vous pouvez obtenir tous les enregistrements de l'historique, vous devez vous souvenir de tous les paramètres. C'est une situation ; il peut en fait y avoir plus de dépendances de processus. Bien sûr, il existe de nombreuses façons de contrôler les processus et il existe de nombreuses bibliothèques pour le prendre en charge. Tels que promesse et asynchrone. Cet article explique uniquement un scénario d'événements et de méthodes liés au processus, qui peuvent vous inspirer.
Je pense que vous maîtrisez la méthode après avoir lu le cas dans cet article. Pour des informations plus intéressantes, veuillez prêter attention aux autres articles connexes sur le site Web chinois de php !
Lecture recommandée :
Explication détaillée de l'utilisation de composants dynamiques personnalisés dans vue
L'utilisation de protobuf.js et Long.js Explication détaillée
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!