Je me plaignais récemment. Tout le monde sait que le Front-end Web est devenu très lourd par rapport à il y a quelques années. Divers cadres JS, divers objets et de nombreux projets, les modules publics seront extraits.
L'affichage de l'interface utilisateur de ces modules est le même, et la différence est la logique d'arrière-plan. Par exemple, lorsque nous faisons des affaires dans les voyages d'entreprise, nous avons généralement un module public JS du centre de coûts. Les clients remplissent ce centre de coûts lors de la réservation de billets d'air. Ce centre de coûts est distribué aux extrémités de la réservation telles que en ligne, hors ligne et application, ce qui est également pratique pour le règlement mensuel avec la société client au stade ultérieur.
Nous savons également qu'après que le projet devient plus grand, compliqué et SOA, de nombreux problèmes surviennent. Tout comme une théorie sur le Web, toutes les données frontales sont non durables, donc les données d'interface de l'autre équipe ne sont pas les mêmes. Lorsque le projet était jeune, il n'était pas si peu confiant et il n'enregistrerait les journaux que lorsque les erreurs logiques. Les processus commerciaux normaux sont généralement rarement enregistrés. Après tout, les journaux d'informations semblent disgracieux, et il consomme également la bande passante du serveur et fait également traîner les performances du Web.
Mais le projet est grand. Un jour, lorsque vous rencontrez un bug étrange dans le projet, vous comptez sur les journaux incomplets et enfin tracez l'interface ligne par ligne à l'œil nu. Cependant, il y a trop de paramètres et il est impossible de restaurer avec précision les données des paramètres d'interface. Cependant, vous êtes sûr à 100% que c'est certainement le problème de retour de l'interface, mais vous ne pouvez pas obtenir le message complet. Pour le moment, vous ne pouvez pas trouver le fournisseur d'interface. J'étais impuissant à ce moment-là. Ce serait formidable si vous pensez qu'il serait préférable d'avoir une connexion dans chaque ligne.
Après avoir appris la leçon, la tendance des journaux des processus d'enregistrement est devenue de plus en plus populaire, et finalement un événement majeur au début de l'année a également été causé. J'ai beaucoup dit d'une manière confuse que le backend Web est comme ça, alors n'avons-nous pas également besoin d'enregistrer des journaux dans le front-end actuel? Nous savons que comme il s'agit d'un module JS public, ce module doit avoir encapsulé certaines méthodes en soi, et il est absolument impossible de laisser des programmes tiers utiliser leurs propres nœuds de texte, tels que les suivants:
La copie de code est la suivante:
<! - Troisième module ->
Société: <entrée type = "Text" id = "Company" value = "xxx Co., Ltd." />
Nom de l'employé: <input type = "text" id = "username" value = "zhang san" />
<! - ->
<script type = "text / javascript">
// Centre de coûts
var costcenter = (function () {
var Company = (document.getElementById ("Company") || "") && document.getElementById ("Company"). Value;
var username = (document.getElementById ("username") || "") && document.getElementById ("username"). valeur;
var result = {
getInfo: function () {
return {Company: Company, nom d'utilisateur: nom d'utilisateur};
},
validation: fonction () {
return boolean (Company && username);
}
};
Résultat de retour;
}) ();
</cript>
Afin de simplifier les opérations, l'interface utilisateur tierce fournit des nœuds d'interface utilisateur pour les noms de l'entreprise et les noms des employés et résume une classe de costumes pour fournir des méthodes de lecture. On peut voir que mon programme programmé n'a besoin que de lire CostCenter.getInfo, qui joue également un rôle dans l'encapsulation.
Mais le problème se produit ici. Dans le projet réel, la valeur ne peut pas être obtenue dans le CostCenter pour diverses raisons. Bien sûr, il peut également s'agir d'un bug dans l'interface utilisateur commune.
Mais à ce moment-là, vous ne saviez pas si la valeur était réellement obtenue, mais logiquement même si la valeur n'était pas obtenue, vous ne pouviez pas empêcher la soumission de l'ordre. Donc, afin de suivre soigneusement le bug, vous avez écrit une classe LogCenter Singleton pour enregistrer le journal. Il y a généralement cette façon d'utiliser JS pour enregistrer les journaux.
<1> ajax
Cette méthode est facile à penser, mais si vous utilisez XMLHttpRequest native, vous devez considérer la compatibilité du navigateur. Cependant, si vous n'avez pas besoin de natifs, vous devez compter sur des cadres tiers, tels que jQuery. Cependant, après tout, il existe encore de nombreuses entreprises qui n'utilisent pas jQuery, donc cela doit être utilisé en fonction des besoins réels.
La copie de code est la suivante:
// Centre-journal
var logCenter = (function () {
var result = {
Info: fonction (titre, message) {
// Opération AJAX
$ .get ("http://xxx.com", {"title": title, "message": message}, function () {{
}, "poste");
}
};
Résultat de retour;
}) ();
<2> image
Il y a un objet appelé Image dans notre DOM, nous pouvons donc attribuer dynamiquement son SRC dans le but de demander l'URL d'arrière-plan, et en même temps, nous devons transmettre des informations sur le titre et le message dans l'URL. Cette façon dynamique d'image.src n'a pas besoin de considérer les problèmes de compatibilité du navigateur, ce qui est très bon.
La copie de code est la suivante:
// Centre-journal
var logCenter = (function () {
var result = {
Info: fonction (titre, message) {
// Opération AJAX
$ .get ("http://xxx.com", {"title": title, "message": message}, function () {{
}, "poste");
},
info_image: fonction (titre, message) {
//image
var img = new image ();
img.src = "http://www.baidu.com?title=" + title + "& message =" + message + "& temp =" + (math.random () * 100000);
}
};
Résultat de retour;
}) ();
Ce qui précède est le principal contenu de cet article, et nous continuerons à en discuter en profondeur à l'avenir