Me he estado quejando recientemente. Todos saben que el front-end web se ha vuelto muy pesado en comparación con hace unos años. Se extraerán varios marcos JS, varios objetos y muchos proyectos, módulos públicos.
La visualización de la interfaz de usuario de estos módulos es la misma, y la diferencia es la lógica de fondo. Por ejemplo, cuando estamos haciendo negocios en viajes corporativos, generalmente tenemos un módulo público JS del centro de costos. Los clientes llenan este centro de costos al reservar boletos de aire. Este centro de costos se distribuye en los extremos de la reserva, como en línea, fuera de línea y aplicación, que también es conveniente para un acuerdo mensual con la empresa cliente en la etapa posterior.
También sabemos que después de que el proyecto se vuelve más grande, complicado y SOA, surgen muchos problemas. Al igual que una teoría en la web, todos los datos front-end no son fruscustables, por lo que los datos de interfaz del otro equipo no son los mismos. Cuando el proyecto era joven, no era tan poco seguro, y solo registraría registros cuando los errores lógicos. Los procesos comerciales normales generalmente rara vez se registran. Después de todo, los registros de información parecen antiestéticos, y también consume ancho de banda del servidor y también arrastra el rendimiento de la web.
Pero el proyecto es grande. Cuando se encuentra con un error extraño en el proyecto un día, confía en los registros incompletos y finalmente trazas la interfaz de línea a simple vista a simple vista. Sin embargo, hay demasiados parámetros y es imposible restaurar con precisión los datos de parámetros de interfaz. Sin embargo, está 100% seguro de que definitivamente es el problema de retorno de la interfaz, pero no puede obtener el mensaje completo. En este momento, no puede encontrar el proveedor de interfaz. Estaba indefenso en ese momento. Sería genial si crees que sería mejor tener un registro en cada línea.
Después de conocer la lección, la tendencia de los registros de procesos de grabación se volvió cada vez más popular, y eventualmente también se causó un evento importante a principios de año. Dije mucho de una manera confundida que el backend web es así, así que no necesitamos registrar registros en el front-end actual? Sabemos que, dado que es un módulo JS público, este módulo debe haber encapsulado algunos métodos por sí solo, y es absolutamente imposible permitir que los programas de terceros operen sus propios nodos de texto, como los siguientes:
La copia del código es la siguiente:
<!-Tercer módulo->
Company: <input type = "text" id = "compañía" value = "xxx Co., Ltd." />
Nombre del empleado: <input type = "text" id = "username" value = "zhang san" />
<!-->
<script type = "text/javaScript">
// Centro de costos
var costcenter = (function () {
var empresa = (document.getElementById ("Company") || ") && Document.getElementById (" Company "). Value;
var userName = (document.getElementById ("username") || ") && document.getElementById (" username "). valor;
resultado var = {
getInfo: functer () {
regreso {Company: Company, UserName: UserName};
},
Validación: function () {
return boolean (empresa && nombre de usuario);
}
};
resultado de retorno;
}) ();
</script>
Para simplificar las operaciones, la interfaz de usuario de terceros proporciona nodos de interfaz de usuario para los nombres de las empresas y los nombres de los empleados, y encapsula una clase CostCenter para proporcionar métodos de lectura. Se puede ver que mi programa programado solo necesita leer CostCenter.getInfo, que también juega un papel en la encapsulación.
Pero el problema ocurre aquí. En el proyecto real, el valor no se puede obtener en el CentCenter debido a varias razones. Por supuesto, también puede ser un error en la interfaz de usuario común.
Pero en ese momento no estaba seguro de si el valor se obtuvo realmente, pero lógicamente incluso si no se obtuvo el valor, en principio no podía evitar el envío de pedidos. Entonces, para rastrear a fondo el error, escribió una clase LogCenter Singleton para grabar el registro. Por lo general, hay esta forma de usar JS para grabar registros.
<1> Ajax
Es fácil pensar en este método, pero si usa XMLHTTPRequest nativo, debe considerar la compatibilidad del navegador. Sin embargo, si no necesita nativo, debe confiar en marcos de terceros, como jQuery. Sin embargo, después de todo, todavía hay muchas compañías que no usan jQuery, por lo que esto debe usarse de acuerdo con las necesidades reales.
La copia del código es la siguiente:
// centro de registro
var logCenter = (function () {
resultado var = {
Información: función (título, mensaje) {
// operación AJAX
$ .get ("http://xxx.com", {"título": título, "Mensaje": Mensaje}, function () {
}, "correo");
}
};
resultado de retorno;
}) ();
<2> Imagen
Hay un objeto llamado imagen en nuestro DOM, por lo que podemos asignar dinámicamente su SRC con el fin de solicitar la URL de fondo, y al mismo tiempo, necesitamos pasar la información de títulos y mensajes a la URL. Esta forma dinámica de Image.Src no necesita considerar los problemas de compatibilidad del navegador, lo cual es muy bueno.
La copia del código es la siguiente:
// centro de registro
var logCenter = (function () {
resultado var = {
Información: función (título, mensaje) {
// operación AJAX
$ .get ("http://xxx.com", {"título": título, "Mensaje": Mensaje}, function () {
}, "correo");
},
info_image: function (título, mensaje) {
//imagen
var img = nueva imagen ();
img.src = "http://www.baidu.com?title=" + Title + "& Message =" + Mensaje + "& Temp =" + (Math.random () * 100000);
}
};
resultado de retorno;
}) ();
Lo anterior es el contenido principal de este artículo, y continuaremos discutiendo en profundidad en el futuro.